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.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Understanding state, nonce, and PKCE”.
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.
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.
Q: What breaks when state is static or predictable in an OIDC login flow?
A: The browser callback becomes forgeable.
Practitioner guidance
- 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.
- Generate unpredictable values for every authorization request Use cryptographically secure random generation for state, nonce, and code_verifier on each login attempt.
- 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.
Bottom line: State, nonce, and PKCE are complementary because each one protects a different step in the OAuth and OIDC flow.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/06/2026 4:14 am
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.
A question worth separating out:
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.
👉 Read our full editorial: OAuth and OIDC need state, nonce, and PKCE to close different gaps