Access Token
A credential that can be used by an application to access an API.
Detailed Explanation
Access tokens tell the API that the 'bearer' of the token has been authorized to access specific resources on behalf of a user. Unlike ID tokens, access tokens are opaque to the client and are meant for the resource server (the API) to consume. They should have limited scope and a short lifespan.
Quick Summary
An access token is the credential a client presents to call a protected API. Its job is authorization, proving the holder has permission for specific actions on specific resources for a limited time.
Key Takeaways
- Sent as `Authorization: Bearer <token>` to the resource server.
- Carry scopes (`read:profile`, `write:billing`) limiting what the holder can do.
- Short-lived (minutes to an hour); refresh tokens issue new ones without re-auth.
- May be opaque (look up in token store) or JWT-formatted (self-validating). JWT scales; opaque revokes easily.
- Audience (`aud`) claim identifies which API the token is for, APIs must reject tokens issued for a different audience.
When to use it
- Any OAuth-protected API call: GitHub, Google APIs, Stripe Connect, Microsoft Graph.
- First-party mobile/SPA → backend calls after a PKCE login.
- Service-to-service auth with the Client Credentials grant.
- Step-up auth flows that issue elevated-scope tokens for sensitive actions only.
Common Mistakes
- Long-lived access tokens, defeat the entire "limit blast radius" design.
- Treating access tokens as opaque to your own backend when they're JWTs, you should validate signature, issuer, audience, and expiry.
- Skipping audience validation; tokens for one API accidentally work on another.
- Overbroad scopes; request the minimum the operation needs, not the maximum the user might consent to.
Access Token, Frequently Asked
Should access tokens be JWTs or opaque?
JWTs scale better, no token store lookup per request, and let APIs validate offline. Opaque tokens are easier to revoke and don't leak claims. Many providers default to JWTs with short TTLs to get both upsides.
Where should the client store access tokens?
In memory if possible. HttpOnly cookies if the backend manages them. Never localStorage in apps that handle untrusted user content, XSS will steal them.