Access Tokens vs Refresh Tokens — A Practical Guide for Backend Developers

Authentication looks simple at first: user logs in, server remembers them.
But at scale, that simplicity breaks down fast.

In this post, I’ll explain why session-based authentication struggles, how token-based authentication solves those problems, and why Access Tokens alone are not enough without Refresh Tokens using real-world reasoning and production-grade practices.

Why Session-Based Authentication Doesn’t Scale

Traditional session-based authentication is stateful.
The server must store session data either in memory (RAM) or in a centralized database.

This creates several problems as traffic grows:

• High memory usage: Storing sessions in RAM limits the number of concurrent users a server can handle.

• Database bottlenecks: Moving sessions to a DB increases latency and can exhaust connection pools under load.

• Poor horizontal scaling: In a multi-server setup, sessions must be shared or synchronized across instances, adding complexity and failure points.

In distributed systems, session replication becomes an architectural liability.
Modern APIs need statelessness and this is where tokens shine.

Tokens: A Simple Analogy

Think of a token like a digital pass or a id-card.

Instead of the server remembering every user session, the server issues a signed token after login.
From that point on, the token itself proves the user’s identity.

Here’s the flow:

1. You log in with your credentials

2. The authorization server verifies them

3. A signed token (usually a JWT) is issued

4. Every request includes that token

5. The resource server verifies the token no session lookup needed

When the token expires, it’s rejected.

A real-world example:
While watching YouTube, your app doesn’t log you out every 15 minutes. When the Access Token expires, the app silently uses a Refresh Token in the background to get a new one without interrupting your experience.

What Exactly Is a JWT?

JWT (JSON Web Token) is a compact, stateless way to transmit claims between parties.
It’s widely used for authorization after authentication.

A JWT has three parts:

1. Header

Contains metadata:

• Token type (JWT)

• Signing algorithm (HS256, RS256, etc.)

2. Payload

Contains claims such as:

• user_id

• roles / scopes

• expiration time (exp)

Important:
JWT payloads are not encrypted only Base64Url encoded. Anyone can decode them.

3. Signature

Ensures the token hasn’t been tampered with.

• HS256 → shared secret key

• RS256 → private key signs, public key verifies

If the signature is valid, the server can trust the claims.

Never store passwords, secrets, or sensitive details inside a JWT.

Why an Access Token Alone Is Dangerous

Access Tokens are bearer tokens.

That means:

Whoever holds the token is the user.

In modern auth systems (OAuth, OpenID), this is risky because:

• Access tokens represent a session that already passed MFA

• If stolen, attackers can bypass MFA entirely

• The attacker can read emails, access cloud data, or impersonate the user

Think of an access token like cash possession equals power.

This is why access tokens must be:

• Short-lived

• Replaceable

• Limited in scope

Access Token vs Refresh Token (Table)

The Full Authentication Flow (Story Style)

Alice opens her favorite app and logs in.

The authorization server verifies her credentials and issues:

• Access Token → valid for 15 minutes

• Refresh Token → valid for 30 days

The access token is sent with every API request.
The refresh token is stored securely in an HttpOnly cookie and tracked in the database.

After 15 minutes:

• The access token expires

• The app sends the refresh token

• A new access token is issued

• Alice keeps using the app uninterrupted

If the refresh token expires or is revoked, Alice must log in again.

Token Storage: Where Most Apps Go Wrong

Why localStorage Is Dangerous

localStorage is accessible via JavaScript and that’s the problem.

If an attacker injects malicious JS (XSS), they can do:

localStorage.getItem("token")

One line is enough to steal the token and impersonate the user.

Why HttpOnly Cookies Are Safer

Cookies marked HttpOnly:

• Cannot be accessed by JavaScript

• Are immune to XSS token theft

Even if XSS occurs, document.cookie won’t expose the token.

Cookies introduce CSRF risk, but:

• SameSite=strict/lax

• CSRF tokens

• Double-submit strategy

…solve that problem cleanly.

In practice, HttpOnly cookies + server-side refresh token storage is the safest balance.

Code Example (From VideoTube: Our Video Sharing Platform)

const generateAccessAndRefreshTokens = async (userId) => {
  const user = await User.findById(userId)

  const accessToken = user.generateAccessToken()
  const refreshToken = user.generateRefreshToken()

  user.refreshToken = refreshToken
  await user.save({ validateBeforeSave: false })

  return { accessToken, refreshToken }
}

Refresh flow with verification and rotation:

const refreshAccessToken = asyncHandler(async (req, res) => {
  const incomingRefreshToken =
    req.cookies.refreshToken || req.body.refreshToken

  if (!incomingRefreshToken) {
    throw new ApiError(401, "Unauthorized request")
  }

  const decoded = jwt.verify(
    incomingRefreshToken,
    process.env.REFRESH_TOKEN_SECRET
  )

  const user = await User.findById(decoded._id)

  if (!user || incomingRefreshToken !== user.refreshToken) {
    throw new ApiError(401, "Invalid refresh token")
  }

  const { accessToken, refreshToken: newRefreshToken } =
    await generateAccessAndRefreshTokens(user._id)

  res
    .cookie("accessToken", accessToken, { httpOnly: true })
    .cookie("refreshToken", newRefreshToken, { httpOnly: true })
    .json({ message: "Access token refreshed" })
})

Common JWT Mistakes I Almost Made

1. Long-lived access tokens → Massive blast radius

2. Storing tokens in localStorage → XSS disaster

3. Putting sensitive data in JWT payloads → Anyone can decode it

4. Not revoking refresh tokens → No real logout

5. Decoding without verifying signatures → Privilege escalation risk

Final Thoughts

Tokens are powerful but only when used correctly.

• Access tokens should be short-lived

• Refresh tokens must be stored securely and revocable

• JWTs should be trusted only after verification

If you design auth assuming compromise will happen, your system survives when it does.