An ID token is a JSON Web Token (JWT) issued by an OpenID Connect provider to identify a user and tell a client application about that user’s authentication.

OpenID Connect (OIDC) adds an identity layer to OAuth 2.0. Its ID token gives the application a defined way to establish who signed in, rather than trying to infer identity from an access token intended for an API. The application still has to validate what it receives before relying on those claims.

What an ID token contains

An ID token identifies its issuer through the iss claim and the user through sub, the subject identifier. The aud claim identifies the intended audience and must include the application’s client ID. It also carries an expiry time and the time it was issued.

Other claims depend on the request and provider configuration. An email address may be available, but it is not a required identity key. Applications should associate the account with the issuer and subject identifier, rather than assuming an email address is permanent or unique across providers.

The familiar signed JWT representation makes its claims readable to anyone holding the token; encoding does not make them confidential. OIDC also supports encrypted ID tokens. The application needs to handle the representation it has agreed with the provider.

How an ID token is validated

In an authorization code flow, the application exchanges a code at the provider’s token endpoint and receives an ID token. Validation establishes that it came from the expected provider and was issued for this application, with acceptable timing and the appropriate protections for the flow.

For a signed token, the client follows the applicable signature-validation requirements using trusted provider keys and the expected algorithm. It checks the issuer and audience, then expiration. If the authentication request included a nonce, the returned value must match. A nonce associates the response with that request and helps prevent replay.

The complete rules vary with the flow and token contents. A maintained OIDC library is preferable to a custom validator that only decodes the payload or checks one claim.

Where identity ends and access begins

Consider a customer signing into an insurance portal. The ID token allows the portal to establish which customer authenticated. Retrieving a policy through a protected API requires the appropriate access token and the API’s authorization checks.

Treating the ID token as an API credential confuses those responsibilities. It can also cause an API to accept a token intended for a different recipient. Shared use of the JWT format does not make token types interchangeable.

An ID token describes an authentication event; it is not a continuous assessment of whether the customer’s device or session remains safe. The portal manages its own session after sign-in, including when a sensitive action needs fresh authentication.

Frequently asked questions

Is an ID token the same as an access token?

No. An ID token conveys authentication and identity claims to the client application. An access token is intended for a protected API and its authorization checks.

Does an ID token always contain the user’s email address?

No. Email is an optional claim. The issuer and subject identifier provide the stable identity association an OIDC client should use.

Does ID-token expiry automatically end the application session?

No. The token’s expiry governs its acceptance. The application manages its session lifetime separately and must decide when fresh authentication is needed.

Related: OpenID Connect (OIDC) · OAuth 2.0 · Identity Provider (IdP) · Authentication vs. Authorization · Single Sign-On (SSO) · Step-Up Authentication