How do access tokens and refresh tokens work together?

Question

IT Interview Practice · Accepted Answer

The two tokens follow a simple lifecycle: a **short-lived access token** authorizes each API call, and a **long-lived refresh token** silently mints new access tokens when they expire — so the user stays logged in without re-entering credentials.

## The flow

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API call: Authorization: Bearer <access>
     ▼
┌────────────┐  verify signature + exp   (no DB lookup)
│ Resource   │ ──── 200 OK ────▶ (access still valid)
│ API        │ ──── 401 ───────▶ (access expired)
└────────────┘
     │  3. on 401: POST /token { refresh }
     ▼
┌────────────┐  verify + rotate
│ Auth server│ ──── new access (+ new refresh) ────▶ retry the call
└────────────┘
```

1. **Login** — the user authenticates once; the server returns an **access token** (short TTL) and a **refresh token** (long TTL).
2. **Access APIs** — the client sends the access token in `Authorization: Bearer …` on every request. The API verifies it statelessly (signature + `exp`) and responds — no session store needed.
3. **Refresh on expiry** — when the API returns `401` (or the client sees `exp` is near), the client POSTs the **refresh token** to the auth server's `/token` endpoint and gets a fresh access token, then retries the original request. The user notices nothing.
4. **Logout / revoke** — the server deletes or denylists the refresh token; the next refresh fails and the session ends (the current access token still dies on its own within minutes).

```js
// Client interceptor: refresh once on 401, then retry.
async function apiFetch(url, opts = {}) {
  let res = await fetch(url, withAuth(opts, accessToken));
  if (res.status === 401) {
    accessToken = await refreshAccessToken(refreshToken); // POST /token
    res = await fetch(url, withAuth(opts, accessToken));   // retry
  }
  return res;
}
```

## Refresh token rotation

Best practice is **rotation**: each refresh call returns a *new* refresh token and invalidates the old one. If an old (already-used) refresh token is presented again, that signals theft — the server revokes the entire token family and forces re-login. This limits the damage of a stolen refresh token.

## Storage

- **Refresh token** → `httpOnly`, `Secure`, `SameSite` cookie so JavaScript (and thus XSS) can't read it.
- **Access token** → kept in memory on the client; short life limits exposure.
- Never put either in `localStorage` if you can avoid it — it's readable by any injected script.

## Why it matters

This flow is the backbone of session management in modern SPAs, mobile apps, and APIs, so interviewers expect you to trace it end to end: issue both at login, authorize with the access token, transparently refresh on expiry, and rotate + revoke for safety. Getting the details right — stateless verification, refresh only at the token endpoint, rotation with reuse detection, and `httpOnly` storage — is the difference between a smooth, secure session and one where a single stolen token means a long-lived account takeover.

The flow

Refresh token rotation

Storage

Why it matters

Related questions