Card 07/ 11
Access Token vs ID Token vs Refresh Token
One is for the API, one is for the app, and one is for getting more of the first.
An OAuth and OpenID Connect flow can return three tokens, each with one audience and one job. The access token is for the API, sent on each call. The ID token is for the client, read once to learn who signed in. The refresh token is for the authorization server, exchanged for a new access token when the old one expires. Sending one where another belongs is a common and serious mistake.
| Property | Access token | ID token | Refresh token |
|---|---|---|---|
| Defined by | OAuth 2.0 | OpenID Connect | OAuth 2.0 |
| Sent to | The resource server, on every call | Nobody; the client keeps it | The authorization server's token endpoint |
| Read by | The API | The client | The authorization server |
| Format | Opaque or JWT, the API's choice | Always a JWT | Usually opaque |
| Typical lifetime | Minutes to an hour | Minutes; used once at sign-in | Days to months, often rotated on use |
| Must never | Be read by the client to identify the user | Be sent to an API as an access token | Leave the client or be sent to an API |
Access token. Its audience is the API. The client should treat it as opaque even if it happens to be a JWT, because the API may change its format.
ID token. Its audience is the client, as its aud says. An API that accepts ID tokens as credentials accepts tokens that were never issued to it and carry no scopes.
Refresh token. It is the most powerful of the three, because it mints new access tokens. Keep it in the most protected storage the client has; for browser apps, current guidance is a back end that holds it, or rotation, where each use returns a new refresh token and invalidates the old.
Choose by audience. API call: the access token. Who signed in: the ID token. Access token expired: the refresh token, at the token endpoint.
← → move through sections and cards