Tokens

A sign-in ends with tokens, and each token has a different reader. The ID token is for your application, and it proves that a sign-in happened. The access token is for the API behind your application. The refresh token is for your server only, so it can get new access tokens. This section says what each contains, how long it lives and which checks to make before you trust it.

It is for developers who receive or verify tokens. If you only want to sign people in, the SDK performs these checks for you, but the pages are still worth reading once to know what it refuses.

Think of three tokens with three audiences. The ID token is a record of an authentication that already happened, so it lives only as long as an access token. The access token is a JWT addressed to one audience, bound to a key, and valid for at most 15 minutes. The refresh token is opaque, used once, and replaced each time. Claims are the contents, and two of them, acr and amr, say how strongly and by what method the person signed in.

ID token       -> your app    "who signed in, how"        verify, then start a sessionaccess token   -> your API    "this caller, this audience" verify signature, audience, proofrefresh token  -> your server "get a new access token"     used once, then replaced

I am verifying an access token in my API.

1. Access token: format, audience and the checks.
2. DPoP verification for resource servers: the proof on each request.
3. Claims reference: what the claims mean.

I am starting a session after sign-in.

1. ID token: the exact steps to verify it.
2. acr and amr values: check how the person signed in.

I am keeping a person signed in.

1. Refresh token: lifetime, rotation and the retry grace.
2. Refresh tokens and offline access: the flow.

Access token answers the token's format (an RFC 9068 JWT), its lifetime (at most 900 seconds, set per client), its audience and the checks your API makes. It also says that local verification cannot see a revocation or an ended session. ID token answers what it proves, every claim it can carry and the exact verification steps before you start a session. Refresh token answers when you get one, how long it lives for first-party and third-party clients, rotation, the retry grace, reuse, binding to a key and what to do when a refresh fails.

Claims reference lists every claim in an ID token, an access token and the userinfo response, with its type, where it appears and which scope releases it. A claim with no value is left out and never sent as null. acr and amr values answers what those claims say about how a person signed in, how to demand a stronger level and how to check the result.

DPoP verification for resource servers answers the exact checks an API makes on a bound token and its per-request proof, how nonces work, what to send when you refuse and what the replay store is for.

Read Sessions and tokens for the plain-words version, and DPoP for how a client holds the key. Local verification needs the public keys, which come from JWKS and key rotation.

Is there a roles claim? No. See Claims reference.

How long does an access token live? At most 15 minutes. See Access token.

Can my application read the access token? It should treat it as opaque and send it. See Access token.

Is a refresh token a JWT? No. It is opaque. See Refresh token.

What does a missing claim mean? It does not apply or was not released. See Claims reference.

It does not cover how tokens are obtained, which is in Flows and Endpoints. It does not cover how a person's authorization is decided, which is in Authorization. The full lifetimes table is in Token lifetimes.