TL;DR: State binds the browser redirect to the original login request, nonce binds the ID token to the current session, and PKCE binds the authorization code to the party that requested it, according to WorkOS. Dropping any one of them reopens a distinct attack path, so OIDC security depends on all three checkpoints working together.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: State, nonce, and PKCE each protect a different point in the OAuth 2.0 and OpenID Connect authorization code flow.
Why it matters: IAM teams need to treat these as complementary controls because removing any one creates a different exploit path in browser redirects, token validation, or code redemption.
Context
OAuth 2.0 and OpenID Connect security depends on controls that are bound to different checkpoints in the login flow, not on one mechanism doing all the work. State, nonce, and PKCE look similar because they are all short random values, but each one answers a different trust question at a different point in the exchange.
For identity teams, the operational risk is not confusion about the protocol terms. The real problem is control overlap assumptions, where a team thinks one check covers the others and quietly leaves a browser redirect, an ID token replay path, or an authorization code interception path exposed.
Key questions
Q: How should security teams implement state, nonce, and PKCE together in OIDC flows?
A: Treat them as three separate checks in one flow. Validate state at the callback, validate nonce after token exchange, and send the PKCE verifier only to the token endpoint. Keep the generated values independent and session-bound so one compromise does not weaken the others.
Q: Why do OAuth and OIDC flows need both nonce and PKCE if the code exchange already uses TLS?
A: TLS protects the transport, not the origin of the token or the rightful redeemer of the code. Nonce blocks replay of a valid ID token into the wrong session, while PKCE blocks interception of the authorization code before the token endpoint issues tokens. They address different trust boundaries, so one does not replace the other.
Q: What breaks when state is static or predictable in an OIDC login flow?
A: The browser callback becomes forgeable. An attacker can plant a callback that carries a valid-looking code and trick the application into accepting an unsolicited response. That reopens CSRF against the redirect step, which is why state must be random, session-bound, and verified before the callback is processed.
Q: Should organisations require PKCE for confidential clients, or only for public clients?
A: Require it for both. Public clients need PKCE because they cannot rely on a client secret, but confidential clients still benefit because PKCE ties the authorization request to the token request. That reduces the impact of intercepted codes and narrows the assumptions a token endpoint must make about the caller.
Technical breakdown
State protects the browser redirect, not the token exchange
State is a browser-session correlation value. The application generates it before redirecting the user to the authorization server, stores it with the current session, and verifies it when the callback returns. That blocks cross-site request forgery on the redirect endpoint because the application can tell whether the callback was initiated by its own login request. State is opaque to the authorization server and has no role in token issuance or ID token validation, so it cannot defend the later stages of the flow.
Practical implication: treat state as callback integrity for the browser redirect and reject any response that does not match the stored session value.
Nonce binds the ID token to the current login session
Nonce is an OpenID Connect freshness check carried inside the ID token itself. The application sends it in the authorization request, and the authorization server echoes it into the token payload, where the client checks it after the code exchange. That design blocks ID token replay because a previously issued token, even if properly signed, must still match the current session’s nonce. It is specific to OIDC because plain OAuth 2.0 does not issue ID tokens. State cannot replace this because state is checked before token delivery, not inside the token.
Practical implication: validate nonce on every ID token path and do not skip it just because the code exchange was completed over a secure back channel.
PKCE proves the redeeming party owns the authorization code
PKCE shifts trust to the token endpoint. The client creates a code_verifier, derives a code_challenge, and sends only the challenge in the authorization request. When the code is later redeemed, the client presents the verifier and the authorization server compares the derived value to the stored challenge. That prevents authorization code interception because a stolen code is useless without the original verifier. PKCE matters for public clients most obviously, but the current best current practice recommends it broadly because it protects the code exchange as its own trust boundary.
Practical implication: require PKCE for all clients and keep the verifier local so intercepted authorization codes cannot be redeemed elsewhere.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Microsoft verified publisher OAuth phishing 2022: Malicious OAuth apps with a fraudulently obtained Microsoft verified publisher badge tricked UK users into granting mailbox access in 2022.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Three short values are not redundant controls, they are three separate trust anchors. OAuth and OpenID Connect break security into the redirect, the token, and the exchange, and each checkpoint needs its own verifier. When teams treat state, nonce, and PKCE as interchangeable, they collapse distinct protections into one assumed control. The implication is that identity programmes must model protocol checkpoints separately, not as a single generic login safeguard.
State, nonce, and PKCE map cleanly to different failure modes in the delegation chain. State answers whether the callback was solicited, nonce answers whether the token belongs to this session, and PKCE answers whether the code is being redeemed by the same party that requested it. That separation matters because a control that is verified at one boundary cannot substitute for a control verified at another. Practitioners should think in terms of checkpoint-specific assurance rather than broad authentication comfort.
OIDC security still fails when teams reuse values or weaken randomness. The article’s real warning is not only to use all three, but to keep them independent and unpredictable. Reusing one value across state and nonce, or deriving state from predictable session data, turns layered verification into a correlated failure domain. Identity architects should design for independent entropy sources and separate validation logic for each checkpoint.
OAuth and OIDC implementation mistakes often look small but create structural exposure. Skipping nonce in the code flow, treating PKCE as optional for confidential clients, or accepting static state values each reopens a known attack path. These are governance failures as much as code defects because they reflect false assumptions about what each protocol element proves. The practitioner takeaway is to audit each checkpoint against its exact trust boundary, not against a generic “authentication passed” result.
What this signals
Checkpoint-specific validation is the governing idea here. Identity teams that collapse redirect integrity, token freshness, and code redemption into one generic login control will miss the fact that each mechanism protects a different trust boundary. That matters operationally because the right failure review is not “did authentication happen?” but “which checkpoint can still be abused if one value is missing or reused?”.
The practical design lesson is to treat browser redirects, token claims, and back-channel redemption as separate policy surfaces. When implementation teams align controls to those three surfaces, they reduce the chance that a single overlooked assumption opens a full login compromise path.
For practitioners
- Bind each checkpoint to a separate validation rule Store state with the browser session, validate nonce inside the ID token, and verify the PKCE code_verifier at the token endpoint. Do not let one mechanism stand in for another.
- Generate unpredictable values for every authorization request Use cryptographically secure random generation for state, nonce, and code_verifier on each login attempt. Never derive them from timestamps, session IDs, or other predictable values.
- Enforce nonce validation in every OIDC login flow Reject any ID token whose nonce claim does not match the session value, even when the token arrives through a seemingly trusted back channel.
- Require PKCE across public and confidential clients Send code_challenge and code_challenge_method on the initial request and require the original code_verifier at redemption so intercepted codes cannot be reused.
Key takeaways
- State, nonce, and PKCE are complementary because each one protects a different step in the OAuth and OIDC flow.
- The main risk is control substitution, where teams assume one parameter can cover a checkpoint it was never designed to protect.
- Practitioners should validate each value at its own boundary and reject any implementation that reuses or predicts these inputs.
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 NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | The article is about authentication gaps in OAuth and OIDC login flows. |
| Recommendation — Apply API2 thinking to reject login flows that cannot prove request origin, token freshness, or code ownership. | ||
| NIST SP 800-63 | SP 800-63C — Federation | OIDC is a federation pattern and the article focuses on validation at federation checkpoints. |
| Recommendation — Use SP 800-63C to align redirect, token, and assertion validation with federation trust boundaries. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | State, nonce, and PKCE depend on correct generation and handling of authenticator-like values. |
| Recommendation — Apply IA-5 to enforce secure generation, storage, and verification of protocol secrets and one-time values. | ||
| NIST Zero Trust (SP 800-207) | Verify explicitly — Verify explicitly | The article is fundamentally about explicit verification at each trust boundary in the flow. |
| Recommendation — Verify each OAuth/OIDC checkpoint explicitly instead of assuming one successful step proves the next one. | ||
Key terms
- State Parameter: A random value sent with an OAuth or OIDC authorization request and returned unchanged on the callback. It binds the browser redirect to the session that initiated it and helps prevent unsolicited callback injection. It does not validate the token itself or prove who redeemed the code.
- Nonce Claim: A one-time value sent in an OpenID Connect request and returned inside the ID token. It proves the token was minted for the current authentication attempt and helps prevent replay. The nonce is checked after token exchange, so it protects token freshness rather than callback integrity.
- PKCE: Proof Key for Code Exchange is a binding mechanism that links the authorization request to the later token exchange. It helps stop authorization code interception and injection by requiring proof that the same client that started the flow is the one completing it.
- Authorization Code Flow: Authorization code flow is the common OAuth pattern where the client first receives a temporary code and then exchanges it for an access token. The design keeps tokens off the front channel and reduces exposure, but it still depends on correct client validation and careful redirect handling.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org