Beta

Create a tenant

A new tenant starts with its own users, OAuth settings, audit history and logs. You are its first Tenant Admin.

BTL Admin

ID tokens and access tokens

All domains, identifiers, and tokens in these examples are fictional.

When the printer asks for sign-in and photo access in one request, the token response can contain two tokens side by side. Both may be JWTs, both come from the same token endpoint, and both are called tokens. They are meant for different readers, and many mistakes with OpenID Connect begin by mixing them up.

Reading an ID token

An ID token is always a JSON Web Token. Here is the one the photo service issues when you sign in to the printer, decoded so that its parts can be read:

Header
{
  "alg": "RS256",
  "kid": "photos-rs-2026-09",
  "typ": "JWT"
}

Claims
{
  "iss": "https://auth.photos.example",
  "sub": "user-2048",
  "aud": "photo-printer",
  "exp": 1790845500,
  "iat": 1790845200,
  "auth_time": 1790845185,
  "nonce": "demo-nonce-3"
}

iss is the issuer, the photo service's exact name. sub, the subject, identifies your account at the photo service. It is the provider's stable identifier for you, and together with the issuer it is how the printer will recognize you next time. aud, the audience, is the printer's client ID. The token is addressed to the printer and to no one else.

iat and exp record when the token was issued and when it stops being acceptable, five minutes later at 09:05 UTC on 1 October 2026. auth_time records when you actually authenticated, at 08:59:45, fifteen seconds before the token was issued. The two can be far apart. Had the photo service relied on a session from earlier in the day, auth_time would show that earlier time. nonce is a value the printer generated for this sign-in attempt and sent in its request, so the token can be matched to that attempt. State and nonce explains how.

The header says the token was signed with RS256, using the photo service's key photos-rs-2026-09. As Digital signatures explained, those are hints for choosing among keys the printer already trusts. Until the signature has been verified and the claims checked, none of these values can be relied on. Validating an ID token and the lessons after it cover each check.

Notice what is missing. There is no name, email address, or scope. This ID token reports an authentication event. Profile information can arrive in other ways, which the lessons from Standard and custom claims onward describe, and some providers add a few profile claims to the ID token as well.

Two tokens, two audiences

The access token in the same response is addressed to the photo API. In the OAuth lessons, the printer carried it to api.photos.example without needing to understand it. It might be a JWT or an opaque string, and its format is a matter between the photo service and its API.

ID tokenAccess token
Who it is forThe printer, named in aud.The photo API.
What it saysWho authenticated, when, and for which request.What access the holder has been granted.
Who checks itThe printer, when you sign in.The photo API, on every request.
Where it goes nextNowhere. The printer reads it and starts a session.In the Authorization header of API requests.
FormatAlways a JWT.Whatever the provider and API use. Often opaque to the client.

Each token is acceptable only to its own reader. Signing someone in with an access token is the shortcut that From delegated access to sign-in warned against. The reverse is just as wrong. If the printer sent the ID token to the photo API as a bearer token, a careful API would reject it: the audience names the printer, not the API, and an API that accepts JWT access tokens checks that the token is typed as an access token, as Token formats and validation explains. An API that skipped those checks would let any application holding one of your ID tokens act with your access.

What an ID token does not do

An ID token is not a session. This one expires five minutes after it is issued, and nobody expects you to be signed out of the printer at 09:05. Once the printer has validated the token, it creates a session of its own, as Staying signed in described, with a lifetime chosen for the printer. By then the ID token has done its job.

It is not permission. The ID token says who you are at the photo service. It does not say what you may do at the printer, and it does not let the printer read your photos.

It is not a live profile either. The token describes one moment. If you change your name at the photo service tomorrow, today's token still describes the old account details, and if the printer copies information into its own records, it has to decide when to refresh them.

Following a complete sign-in traces the whole exchange, from the moment you select Continue to the moment the printer's own session begins.

Try it in the Lab

PUT IT INTO PRACTICE

Check your understanding

Try these questions before moving on. If an answer isn't right, use the feedback and try again.

0 of 2 answered correctly

Enable JavaScript to answer these questions and save progress in this browser.

QUESTION 1 OF 2The printer wants to retrieve your photos. Which token belongs in the Authorization header of its request to the photo API?

QUESTION 2 OF 2Your ID token expires at 09:05. What happens to your printer session at 09:05?

We value your privacy

We use cookies and similar technologies to enhance your browsing experience, and analytics to understand our traffic. By clicking "Allow All", you consent to optional analytics. Cookie Policy

Learn identity