An OpenID Connect nonce is a single-use value sent in an authentication request and returned in the ID token. The client checks that it matches the original value to link the token to the same browser session and reduce replay or token substitution attacks in federated sign-in flows.
What the OpenID Connect nonce does
The nonce is a one-time value that binds an ID token to the authentication request that created it. In practice, it helps the relying party tell whether the token was issued for the same browser session rather than copied from somewhere else, which makes it a core anti-replay check in federated sign-in.
Because the nonce is carried through the authentication round trip and compared on return, it complements other OIDC checks rather than replacing them. The client still needs to validate the issuer, audience, signature and token timing, but the nonce adds a session-specific link that is especially useful when browser redirects and third-party authentication are involved.
Why nonce validation matters in sign-in flows
A nonce reduces the value of a stolen or reused ID token. Without it, a token that is structurally valid may be accepted in the wrong browser session, which can open the door to replay or token substitution attacks. That matters most where an attacker can intercept redirects, reuse stale responses, or try to replay an earlier login artifact into a fresh session.
It also helps prevent subtle mix-up between concurrent login attempts. If a user opens multiple tabs, retries sign-in, or moves between devices, the nonce gives the client a way to reject an authentication response that does not correspond to the original request state. For a practical explanation of the surrounding protocol mechanics, see the OpenID Connect Core 1.0 specification.
Where nonce fits among other OIDC checks
The nonce is one control in a broader token-validation chain. It is checked after the ID token is received, alongside claims and cryptographic verification, and it is only useful if the application preserves enough request state to compare the returned value accurately. If that state is lost, overwritten or shared incorrectly, the nonce check can no longer prove that the response belongs to the original browser session.
Nonce handling also depends on good session hygiene. A nonce should be unique per authentication request, used once, and discarded after validation so it cannot be replayed later. In federated sign-in architectures, that requirement sits naturally next to federation trust, session validation and token handling guidance such as OAuth 2.0 and OpenID Connect Guide for Identity Teams and Identity Provider and SSO Security Guide.
Nonce failures, mistakes and operational consequences
Common implementation errors include omitting nonce checks where they are expected, reusing the same nonce across requests, failing to bind the nonce to the browser session, or accepting a response even when the returned value does not match. Those mistakes turn a defensive request marker into a weak or meaningless field, which defeats one of the main replay protections in OpenID Connect.
When nonce validation is missing or broken, the consequence is not just a theoretical protocol flaw. It can let an attacker reuse a valid ID token, misassociate an identity with the wrong session, or exploit a partially compromised browser flow to complete sign-in as another user. That is why nonce validation belongs in the same review set as SAML vs OIDC Guide and, for related federation patterns, OpenID Federation and Trust Chains Guide.
Risk and Threat Considerations
The main risk is that a valid-looking ID token can be replayed or substituted into the wrong browser session if the client does not verify the nonce correctly. In federated sign-in, that can turn a successful authentication into account confusion, unwanted session creation or unauthorized access through a token that was never meant for that browser instance.
Failure mechanism: An attacker reuses an intercepted or previously issued ID token, or an implementation accepts a response without matching the nonce to the stored request state.
Impact: The relying party may accept an authentication response for the wrong session, which can enable replay, token substitution and unintended sign-in completion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while 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 | V10 — OAuth and OIDC | Nonce validation is part of OIDC authentication integrity and token binding. |
| Recommendation — Verify OIDC nonce handling and reject ID tokens that do not match the originating request state. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Nonce use supports federated authentication integrity and replay resistance. |
| Recommendation — Apply federated authentication controls that bind responses to the original transaction state. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | OIDC nonce strengthens user authentication session integrity. |
| Recommendation — Enforce authentication checks that tie sign-in assertions to the correct user session. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Nonce misuse can weaken authentication integrity in token-based flows. |
| Recommendation — Detect and prevent authentication responses that can be replayed or substituted. | ||
Practitioner Guidance
Why practitioners should care: Treat the nonce as a session-binding control, not a decorative parameter. It should be generated per authentication attempt, stored safely for the duration of that attempt, and invalidated immediately after comparison so it cannot be reused.
What to watch for: Investigate any sign-in implementation that reuses nonces, shares request state across users or tabs, or validates ID tokens without a strict nonce match where the flow depends on one. Those patterns usually indicate that session binding is weaker than the protocol assumes.
Related resources from NHI Mgmt Group
- What is OpenID Connect (OIDC) and how does it extend OAuth 2.0 for NHIs?
- Why does JWE matter in OAuth and OpenID Connect flows?
- What is the difference between SAML and OpenID Connect for enterprise access?
- Why do OAuth and OpenID Connect integrations create IAM risk even when they reduce password use?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org