Notifications
Clear all
Topic starter
06/06/2026 2:31 am
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.
NHIMG editorial — based on content published by WorkOS: Understanding state, nonce, and PKCE
Questions worth separating out
Q: How should security teams implement state, nonce, and PKCE together in OIDC flows?
A: Treat them as three separate checks in one flow.
Q: Why do OAuth and OIDC flows need both callback protection and token validation?
A: Because the redirect and the token are different trust boundaries.
Q: What do teams get wrong about PKCE in enterprise authentication?
A: They often treat PKCE as optional when a client secret exists.
Practitioner guidance
- Generate independent values for each OIDC checkpoint Create separate cryptographically random values for state, nonce, and code_verifier on every authorization request.
- Enforce callback validation before any session advancement Reject unsolicited redirects as soon as the callback arrives if state is missing or mismatched.
- Treat nonce as a mandatory OIDC login check Decode the ID token after exchange and compare the embedded nonce to the value stored for that login attempt.
What's in the full article
WorkOS's full article covers the protocol mechanics this post intentionally leaves at the framework level:
- Step-by-step examples of how state is generated, stored, and validated in the browser callback.
- JWT payload examples showing how nonce is embedded and checked after the code exchange.
- PKCE generation and verification details for the code_challenge and code_verifier pair.
- Common implementation mistakes that break each safeguard in real production flows.
👉 Read WorkOS's explanation of state, nonce, and PKCE in OIDC flows →
State, nonce, and PKCE: are your OIDC controls covering every checkpoint?
Explore further
06/06/2026 4:14 am
Authentication assurance fails when redirect integrity, token freshness, and code possession are collapsed into one control. State, nonce, and PKCE each protect a different checkpoint in the OAuth and OIDC flow, and that separation is the point. When teams treat them as interchangeable, they leave the browser callback, the ID token, or the token endpoint exposed to a different class of abuse. The practitioner conclusion is simple: identity assurance in federation is only as strong as the weakest checkpoint-specific control.
A few things that frame the scale:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to the same study.
A question worth separating out:
Q: How can IAM teams tell whether OIDC hardening is complete?
A: A complete implementation has unique state, nonce, and PKCE values per request, validates each one at the correct checkpoint, and rejects any login that skips a step. If one parameter is reused, static, or unverified, the flow still has a known bypass path.
👉 Read our full editorial: OAuth and OIDC need state, nonce, and PKCE to close different gaps
