Refresh Token Flow (Concept)
On this page
Why Refresh Tokens Exist
Short-lived access tokens reduce the blast radius of token theft. Refresh tokens allow the client to obtain new access tokens without prompting the user to log in repeatedly.
Access Token vs Refresh Token
- Access token: short TTL (minutes), used on every request
- Refresh token: longer TTL (days/weeks), used only to refresh
Rotation Is Not Optional
In production, refresh tokens should be rotated: each refresh issues a new refresh token and invalidates the old one. This limits replay if a token is stolen.
Refresh Flow Example
POST /auth/refresh
Cookie: refresh_token=rt_...
# Response
{
"accessToken": "eyJhbGciOi...",
"expiresIn": 900
}
Set-Cookie: refresh_token=rt_new; HttpOnly; Secure; SameSite=Lax
Storage and Revocation
Store refresh tokens server-side (hashed) with metadata: userId, deviceId, issuedAt, lastUsedAt, and revokedAt. Support device-level logout by revoking a single refresh token record, and global logout by revoking all records for a user.
Production Pitfalls
- Long-lived access tokens (defeats the model)
- No rotation (stolen token remains valid)
- Storing refresh tokens in localStorage (XSS risk)