Why do you need both an access token and a refresh token?

Question

IT Interview Practice · Accepted Answer

The two tokens exist to resolve a direct conflict: an access token must be **sent on every request** (so it's exposed a lot), yet you also want sessions that **last a long time** without forcing frequent logins. You can't have both safely in one token — so you split the job.

## The two roles

- **Access token** — short-lived (typically 5–15 minutes), sent in the `Authorization` header on every API call. Because it's transmitted constantly, a leak is likely; keeping it short means a stolen one expires almost immediately.
- **Refresh token** — long-lived (days/weeks), sent **only** to the auth server's token endpoint to obtain new access tokens. It travels rarely, can be stored more securely, and can be revoked server-side.

```
Login ──▶ access (15m) + refresh (30d)
Every API call ──▶ send access
Access expired ──▶ send refresh ──▶ new access (+ rotated refresh)
```

## Why not just one token?

| | One long-lived access token | Access + refresh |
|---|---|---|
| Exposure | Sent every request, lives long → big theft window | Access short-lived; refresh rarely sent |
| Revocation | Hard (stateless JWT can't be un-issued) | Revoke the refresh token; access dies within minutes |
| UX | Re-login often if short | Stays logged in without re-entering credentials |
| Blast radius of leak | Large | Small (access expires fast) |

- **One short access token, no refresh** → secure, but the user is logged out every few minutes. Terrible UX.
- **One long access token** → great UX, but a leaked token is valid for a long time and can't be easily revoked.
- **Access + refresh** → short exposure window *and* long sessions. The refresh token is the only long-lived secret, and it lives in one safe place.

## What the split enables

- **Revocation despite stateless access tokens.** You can't invalidate a JWT access token before it expires, but you *can* delete/deny the refresh token, so the session ends at the next refresh (within minutes).
- **Refresh token rotation** — issue a new refresh token on each use and detect reuse of an old one (a sign of theft), then revoke the whole chain.
- **Least exposure** — the long-lived secret (refresh) is sent to exactly one endpoint, ideally stored in an `httpOnly` cookie, out of reach of XSS.

## Why it matters

This is the standard modern auth design, and interviewers ask it to see whether you understand the *why*, not just the *how*. The key insight is the trade-off: statelessness and short exposure (access) versus long sessions and revocability (refresh). Getting it wrong — a long-lived access token, no rotation, refresh stored in `localStorage` — turns a single leaked token into a long-lived account compromise. Naming the split and what each token buys you is what a security-aware engineer is expected to know.

	One long-lived access token	Access + refresh
Exposure	Sent every request, lives long → big theft window	Access short-lived; refresh rarely sent
Revocation	Hard (stateless JWT can't be un-issued)	Revoke the refresh token; access dies within minutes
UX	Re-login often if short	Stays logged in without re-entering credentials
Blast radius of leak	Large	Small (access expires fast)

The two roles

Why not just one token?

What the split enables

Why it matters

Related questions