An ID token is a signed identity assertion that proves who authenticated to an application. In OpenID Connect, it carries claims such as subject, issuer, audience, and authentication time, allowing the relying party to establish user identity and session context without using the token as an access credential.
What an ID token does in OpenID Connect
An ID token is not an access token. Its job is to let the relying party establish that authentication happened and to bind that event to a specific subject, issuer, audience and time context.
That distinction matters because the token is meant for identity assertions, not for calling APIs. When teams blur those roles, they weaken the security model and create confusion about what the application is allowed to trust.
For the protocol background, OpenID Connect Core 1.0 defines how ID tokens layer identity information on top of OAuth 2.0 for authentication and single sign-on.
Core claims and trust boundaries
The value of an ID token comes from the claims it carries and the trust relationship behind its signature. The relying party checks issuer, audience and authentication time to decide whether the token is meant for it, whether it came from the expected identity provider, and whether the session is fresh enough for the requested action.
Those checks are what keep an ID token from becoming a generic login artifact. If a token is accepted outside its intended audience, or without verifying the signature and issuer, the application may accept an identity assertion it should never trust.
RFC 6749: The OAuth 2.0 Authorization Framework provides the underlying authorization framework, while the OpenID Connect layer adds the authenticated identity context that applications consume.
How ID tokens fit into application sessions
An ID token often helps bootstrap an application session, but the session should be established by the application after it validates the token, not by treating the token itself as a reusable credential everywhere. That separation limits the blast radius if the token is copied, logged or replayed in the wrong place.
In practice, good implementations treat the ID token as proof of authentication at a specific moment, then move to a separate session mechanism for ongoing access. This is why token handling, audience restriction and expiry semantics all matter to the design.
For deployment guidance on these boundaries, RFC 9700: Best Current Practice for OAuth 2.0 Security gives current security guidance for protecting OAuth deployments against token misuse and replay.
Where ID tokens fail in real systems
ID tokens fail most often when organisations over-trust them. Common mistakes include accepting an ID token as an API bearer token, skipping issuer or audience validation, mixing tokens across clients, or storing tokens in places where they can be exposed through logs, browser storage or debugging tools.
They also fail when the surrounding identity flow is weak. If the authentication step is phishable, if the token can be replayed, or if the relying party does not verify the token’s intended recipient, the signed assertion becomes a liability rather than a control.
To harden the surrounding flow, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens show how sender-constrained designs reduce replay value when tokens are intercepted.
Risk and Threat Considerations
ID tokens become dangerous when they are treated as transferable proof of identity instead of as scoped assertions tied to a specific client and authentication event. If an attacker captures one, the token can expose user identity context, extend session abuse, or help an application accept a forged login state.
Failure mechanism: The application skips validation, misbinds the audience, or reuses the token outside the intended flow, which lets a stolen or misissued assertion drive unauthorized access.
Impact: An attacker may impersonate a user inside the relying party, persist in a session, or pivot from identity compromise into data exposure and account takeover.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V6 — Authentication | ID tokens are part of application authentication and identity assertion handling. |
| Recommendation — Verify token validation logic, issuer checks and authentication flow handling for the relying party. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Defines authenticated identity proofing and token-based authentication assurance concepts. |
| Recommendation — Apply digital identity assurance guidance when designing how the application accepts and trusts identity assertions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The relying party must identify and authenticate users before establishing a trusted session. |
| IA-5 — Authenticator Management | Token handling depends on secure lifecycle control of authenticators and related secrets. | |
| AU-2 — Event Logging | Identity assertion handling should be logged for authentication and replay investigation. | |
| Recommendation — Require strong user authentication before accepting an identity assertion for session establishment. Manage token-related authenticators and credentials so they cannot be reused or exposed improperly. Log token validation and authentication events to support incident review and misuse detection. | ||
Practitioner Guidance
Why practitioners should care: The token is only safe when the application validates it as an identity assertion, not as a general access credential. That means the implementation must preserve the boundary between authentication evidence and API authorization.
Common misunderstanding: Teams often assume a signed token is automatically safe because it is signed. Signature validity is necessary, but it is not sufficient without issuer, audience and freshness checks, plus disciplined handling of where the token may be used.
Practitioner takeaway: Design the application so the ID token proves login, then hand off to a separate session and authorization model that does not depend on the token being reusable elsewhere.
Related resources from NHI Mgmt Group
- Guide: OAuth 2.0 and OpenID Connect Guide for Identity Teams
- What is the difference between an ID token and an access token in OpenID Connect?
- What breaks when an OIDC connection assumes all profile claims are in the ID token?
- How do you configure access token lifetimes in Microsoft Entra ID?
- How do you customise token claims for applications in Microsoft Entra ID?