How Access and Refresh Tokens Work
Source: Dev.to
Simple login flow
- You request “Login with Google”.
- The app redirects to the Authorization Server (Google), which authenticates you and returns an authorization code.
- The app exchanges that code for an access token (and a refresh token).
- The app uses the access token to call the Resource Server on your behalf.
The Authorization Server handles who you are; the Resource Server handles what you’re allowed to do.
The Access Token
Think of the access token as a daily pass. Every request to the Resource Server includes this token, and the server validates it before responding.
- Short‑lived – typically minutes to a few hours.
- Frequent exposure – travels with almost every request, so a short lifespan limits the damage if it’s intercepted.
A long‑lived access token would be a security nightmare because an attacker could use it for an extended period.
The Refresh Token
When the access token expires, the app silently uses the refresh token to obtain a new access token from the Authorization Server—no user interaction required.
- Long‑lived – days, weeks, or even months.
- Rarely transmitted – only sent to the Authorization Server, never to the Resource Server.
- Purpose‑specific – used solely to get new access tokens.
This separation keeps the refresh token safer and makes it easier to revoke if needed.
Quick Comparison
| Aspect | Access Token | Refresh Token |
|---|---|---|
| Lifetime | Minutes‑to‑hours | Days‑to‑months |
| Exposure | Sent with every API request | Sent only to Authorization Server |
| Purpose | Authorize resource access | Obtain new access tokens |
| Revocation | Usually short‑lived, less impact | Can be revoked centrally |
Why Not Use a Single Token?
A single long‑lived token sent with every request would be a security disaster. If stolen, an attacker would have unrestricted access for a long time. Splitting responsibilities:
- Access token – short‑lived, limits exposure risk.
- Refresh token – long‑lived, rarely exposed, easy to revoke.