Explain Access Token and Refresh Token architecture.
Access Token and Refresh Token architecture uses short-lived access tokens for resource access and long-lived refresh tokens to obtain new access tokens without re‑authentication, balancing security and user experience.
In modern applications (especially SPAs, mobile apps, and APIs), the Access Token and Refresh Token pattern separates authorization from long‑term credential storage. An Access Token is a short‑lived credential (typically 5–15 minutes) that proves the user’s permission to access protected resources. It is sent with each API request, often in an Authorization: Bearer header. A Refresh Token is a longer‑lived credential (days or months) that is stored securely (e.g., in an httpOnly cookie or a mobile secure storage). When the Access Token expires, the client uses the Refresh Token to request a new Access Token from a dedicated endpoint, avoiding the need for the user to log in again. This architecture limits the damage if an Access Token is stolen, while Refresh Tokens can be revoked or rotated.
- 1
Access Token – Short-lived (minutes), contains claims (user ID, roles, scopes), sent with every request, stateless validation, larger attack surface if leaked (but short window).
- 2
Refresh Token – Long-lived (days or months), stored securely (httpOnly cookie or server‑side), never sent to resource servers, used only at the refresh endpoint, can be revoked or rotated.
- 3
Benefits – Enhanced security (short exposure window), seamless user experience (no frequent logins), scalability (stateless access tokens), and ability to revoke refresh tokens for logout or security events.
Implementing this pattern properly requires careful security considerations. Refresh tokens should be stored with httpOnly, Secure, SameSite=Strict flags when using cookies. Alternatively, in mobile apps, use secure storage (e.g., Keychain/Keystore). Rotation — issuing a new refresh token each time the access token is refreshed — prevents replay attacks and allows detecting token theft. Servers must store refresh token fingerprints (e.g., hashed) and track their revocation status. Finally, use short access token lifetimes (e.g., 15 minutes) to force frequent refreshes and limit the damage window.