ID Token vs Access Token vs Refresh Token in Plain English
These token types are not interchangeable. Know which token proves login, which one authorizes APIs, and which one should stay out of front-end logs and requests.
Tip
Decode a small sample first and confirm whether you are changing representation, changing structure, or actually protecting content.
Auth debugging gets messy the moment a team calls every token a JWT and treats them as interchangeable.
They are not interchangeable. The safest shortcut is to ask what each token is for before you ask how it is encoded.
The plain-English version
ID token: proves that the user authenticated to the client
Access token: lets a client call an API
Refresh token: gets new tokens without sending the user through login again
A token can be a JWT and still belong to any one of those roles. Format is not purpose.
What an ID token is for
An ID token is primarily for the client application. It carries identity information about the authentication event and the authenticated user.
Typical clues:
- the audience is the client application
- OIDC claims like
nonceor profile details may be present - it is not meant to be your generic API authorization token
What an access token is for
An access token is for the resource server or API. The API uses it to decide whether the caller should be allowed to do something.
That means the API should care about:
- audience
- scope or permissions
- issuer
- expiry
- sometimes token introspection, depending on the provider
What a refresh token is for
A refresh token is not for API calls and not for front-end debugging screenshots. Its job is to obtain new tokens from the authorization server.
Failure case to watch:
Wrong: send refresh token to API
Wrong: log refresh token in browser console
Right: keep it out of normal request flows and protect it as long-lived credential material
Why teams mix them up
- All three may arrive during the same auth flow.
- Some are JWTs and look structurally similar.
- Provider dashboards and SDKs often surface them together.
- A copied code sample may name a generic
tokenvariable and hide the distinction.
A practical debugging workflow
- Use JWT Decode to inspect any token that is actually JWT-shaped.
- Check
aud,iss,scope, and token-specific claims before you assume the token belongs in the current step. - Use JWT Verify when you need to validate a JWT locally.
- If the question becomes "is this still active right now?" rather than "what does it say?", move to the token introspection decision.
Common questions
Can an access token also be a JWT?
Yes. Many access tokens are JWTs, but not all of them are. Some providers use opaque access tokens instead.
Should my API accept an ID token?
Usually no. An ID token is about authentication to the client, not generic authorization to an API.
Why is the refresh token treated more carefully?
Because it can mint new tokens. In practice, that makes it closer to credential material than to an ordinary request artifact.
Developer workflow
Use this guide as a representation check before you move bytes between an API, token, URL, or file format.
- Encode or decode a small sample first, not the production payload.
- Confirm whether the step changes only representation or changes the underlying structure.
- Keep the original and transformed values together until the receiving system accepts the result.
1. raw bytes or text
2. encode/decode for transport
3. decode back to confirm round trip
4. send only after structure still matches