The gap OAuth 2.0 left open

OAuth 2.0, released in 2012, was designed to answer one question only: “can this application perform this specific action on the user’s behalf?” It hands out access tokens — scoped, revocable permissions — but deliberately says nothing standardized about who the underlying user actually is. For years, developers still needed to know “who is logged in right now,” so many of them improvised: they’d take the access token, use it to call an API like “get my profile,” and treat a successful response as proof of identity. This workaround was inconsistent across providers and, worse, created real security holes, because an access token’s meaning is defined only by whichever API accepts it — it was never designed to be a trustworthy identity statement.

What is an ID Token?

An ID Token is a compact, digitally signed piece of data, introduced by OpenID Connect in 2014, that makes a formal, verifiable statement: “this specific user authenticated with us, at this specific time, and here are some verified facts about them.” Unlike an access token, an ID Token is meant to be read directly by the application, not sent onward to an API. It is built using a widely adopted format called a JWT (JSON Web Token), which lets any application verify its authenticity using nothing but a public key — no extra network call required.

Why “ID Token” and “access token” are so often confused

Both are issued at almost the same moment, by the same server, during the same login flow — which is exactly why beginners mix them up. The cleanest way to separate them: the access token is a permission slip for machines (APIs), while the ID Token is an identity certificate for the application itself.

• End User: The human being who logs in and whose identity the ID Token describes.
• Relying Party (RP): The application requesting login — this is the party that will read and trust the ID Token.
• OpenID Provider (OP): The trusted authority (Google, Microsoft, Okta, Auth0, a company’s own identity system) that authenticates the user and issues the ID Token.
• JSON Web Key Set (JWKS): A publicly available set of cryptographic keys, published by the OpenID Provider, that any Relying Party can use to verify an ID Token’s signature.
• Discovery Document: A well-known, standardized JSON file the OpenID Provider publishes, listing its endpoints and public keys so Relying Parties can configure themselves automatically.

The three parts of a JWT-based ID Token

Every ID Token, structurally, is three sections joined by dots, each separately encoded:

graph TD
    OP["OpenID Provider"] -->|Publishes| JWKS["JSON Web Key Set (public keys)"]
    OP -->|Issues| IDT["ID Token: Header + Payload + Signature"]
    IDT -->|Delivered to| RP["Relying Party / Application"]
    RP -->|Fetches once, caches| JWKS
    RP -->|Verifies signature using| JWKS
    RP -->|Reads claims: sub, iss, aud, exp| USER["Establishes who the user is"]
    

The most important claims inside the payload

• iss (Issuer): The exact identity of the OpenID Provider that created the token — the application must confirm this matches the provider it actually trusts.
• sub (Subject): A stable, unique identifier for the user, guaranteed by the provider never to be reassigned to a different person.
• aud (Audience): The specific application this token was issued for — critical, because it prevents a token meant for App A from being reused to log into App B.
• exp (Expiration): The exact timestamp after which the token must be rejected, no matter how valid it looked a moment earlier.
• iat (Issued At): The timestamp when the token was created, useful for detecting unusually old tokens.
• nonce: A random value the application generated before starting login, echoed back inside the token, specifically to block replay attacks.
• Optional profile claims: Depending on requested scopes, the token (or a companion UserInfo endpoint) may include email, name, or picture.

How signature verification actually works

When an application receives an ID Token, it does not simply trust the claims written inside — anyone could type arbitrary text into a JWT-shaped string. Instead, the application recalculates the expected signature using the OpenID Provider’s public key (fetched from the JWKS endpoint) and compares it against the signature attached to the token. If even a single character in the header or payload changed after signing, the recalculated signature will not match, and the token is rejected outright. This is what makes the ID Token “self-contained and verifiable” — no phone call to the OpenID Provider is needed at verification time.

The full mandatory validation checklist

A correct OpenID Connect implementation must check all of the following before trusting an ID Token — skipping even one has caused real vulnerabilities in production systems:

1. Signature is valid, using the correct public key and algorithm
2. iss matches the expected OpenID Provider exactly
3. aud matches this application’s own registered client ID
4. exp has not passed
5. nonce, if one was sent, matches what the application originally generated

sequenceDiagram
    participant Browser
    participant RP as "Relying Party (App)"
    participant OP as "OpenID Provider"
    Browser->>RP: 1 User clicks "Sign in"
    RP->>Browser: 2 Redirect to OP with scope=openid and a nonce
    Browser->>OP: 3 User authenticates
    OP->>Browser: 4 Return authorization code
    Browser->>RP: 5 Deliver code
    RP->>OP: 6 Exchange code for tokens (back-channel)
    OP->>RP: 7 Return ID Token and access token
    RP->>RP: 8 Verify ID Token signature, claims, nonce
    RP->>Browser: 9 Establish local session (cookie)
    

Step-by-step lifecycle

1. Request: The application includes the special openid scope, plus a freshly generated nonce, when redirecting the user to the OpenID Provider.
2. Issuance: After successful login, the OpenID Provider creates and signs the ID Token, embedding the requested claims.
3. Delivery: The ID Token arrives at the application, typically via the secure back-channel token exchange step.
4. Verification: The application runs the full validation checklist described in Chapter 3.
5. Consumption: The application reads the identity claims once, creates its own session (usually a cookie), and then generally discards the ID Token entirely.
6. Expiration: Even if it were kept around, the ID Token becomes worthless the moment its exp timestamp passes.

Key risks and their defenses

• “None” algorithm attack: Some early JWT libraries allowed a token’s header to declare “no signature algorithm,” which some careless implementations then blindly trusted. Modern libraries explicitly reject this, but it’s a cautionary lesson in never trusting a token’s own claims about how it should be verified.
• Algorithm confusion attacks: An attacker tries to trick a server expecting an asymmetric signature (RS256) into instead validating with a symmetric method (HS256) using a key it can guess or already knows. Defense: explicitly pin the expected algorithm rather than trusting whatever the token header claims.
• Missing audience check: Skipping the aud validation lets a token legitimately issued for one application be replayed to authenticate against a different one.
• Replay attacks: Without nonce validation, a captured ID Token could theoretically be resubmitted. The nonce ties each token to one specific login attempt.
• Storing sensitive data inside claims: Because the payload is only encoded, not encrypted, anyone who obtains the token can read its contents — never place passwords, secrets, or highly sensitive personal data inside an ID Token.

Encrypted ID Tokens

For situations demanding confidentiality of the claims themselves (not just tamper-evidence), OpenID Connect also supports an optional encrypted variant, nested inside another JWT layer. This is less common in everyday consumer logins but appears in higher-assurance enterprise and government identity systems.

What to log

• Every ID Token validation failure, tagged by reason (bad signature, expired, wrong audience, wrong issuer, nonce mismatch)
• JWKS key rotation events, including the key identifier used for each validation
• Clock-skew related rejections, since these often point to infrastructure drift rather than genuine attacks

Caching the JWKS correctly

Fetching the JWKS on every single login would be wasteful and slow, so applications cache it — but caching it forever is dangerous, because it would miss legitimate key rotations. Best practice is to cache the JWKS for a reasonable period (commonly a few hours) and refresh immediately whenever a token references a key identifier that isn’t in the current cache.

Recommended patterns

• Verify, then translate: Validate the ID Token fully, extract only the claims you actually need, then immediately create your own internal session — don’t keep passing the raw token around your system.
• Pin the expected algorithm: Explicitly configure which signing algorithm your application expects, rather than reading it from the token itself.
• Use library-provided validation, not hand-rolled parsing: Mature OpenID Connect libraries implement the full checklist correctly; writing your own JWT parser from scratch is a common source of subtle bugs.
• Separate identity from authorization: Use the ID Token purely to establish who the user is, and a separate mechanism (roles, permissions, scopes) to decide what they can do.

Best practices

• Always validate every item on the full checklist from Chapter 3 — never skip even one for convenience.
• Generate a fresh, cryptographically random nonce for every single login attempt; never reuse one.
• Use a well-maintained OpenID Connect library rather than writing custom JWT parsing logic.
• Keep the application’s system clock synchronized (via NTP) to avoid false expiration or “not yet valid” rejections.
• Rotate signing keys periodically on the provider side, and make sure Relying Parties handle key rollover gracefully.

Common mistakes teams actually make

You should not. ID Tokens are meant for the application itself to establish identity, not for authorizing API calls — that is the access token’s job.

Not by default — it’s signed, not encrypted, meaning its contents are readable by anyone who obtains it, but cannot be altered without detection. Encrypted variants exist but are far less common.

Skipping nonce validation removes a key defense against replay attacks, where a previously issued, still-valid ID Token could be resubmitted by an attacker to impersonate a login event.

Email addresses can change or be reused over time, but the sub claim is guaranteed by the OpenID Provider to be a stable, unique identifier for that user — always prefer it as your primary key for identifying accounts.

Generally no — most applications read it once, extract the needed claims, establish their own session, and discard the token. Long-term storage of raw ID Tokens is rarely necessary and adds unnecessary risk.