OAuth State, Nonce and PKCE

How OAuth state, nonce, and PKCE work together

OAuth state, nonce, and PKCE solve different but related problems in the same flow. State preserves request continuity, nonce ties an authentication response to the original sign-in event, and PKCE adds proof that the client that started the flow is the one completing it.

They are often deployed together because modern login journeys cross browsers, apps, redirect handlers, and token endpoints. When used correctly, each control narrows a different replay or substitution path without changing the core OAuth model.

Why each control exists

State is primarily a correlation value. It helps the client verify that the callback it receives belongs to the user action it initiated, which reduces callback mix-up and CSRF-style abuse in authorization redirects.

Nonce is an OpenID Connect concept that helps bind an ID token to a specific authentication transaction. It matters most where the application relies on the token as evidence of the sign-in event, not just on access to an authorization code.

PKCE, described in RFC 9700: Best Current Practice for OAuth 2.0 Security, adds a one-time verifier and challenge so a stolen authorization code is far less useful to an attacker. It is especially important in public clients, mobile apps, desktop apps, and browser-based flows where a client secret cannot be safely protected.

What these controls protect against

These controls mainly address interception, replay, and request substitution. If an attacker can observe redirects, steal a code, or inject a forged callback, state and PKCE make it harder to turn that exposure into a successful token exchange, while nonce helps prevent token replay inside the authentication layer.

They also reduce confusion between multiple concurrent login attempts. Without a strong per-request correlation value, one browser session or app instance can accidentally accept a response meant for a different session, which is a common failure mode in real integrations.

For the underlying protocol mechanics, RFC 6749: The OAuth 2.0 Authorization Framework remains the core reference, while OpenID Connect Core 1.0 defines nonce in the authentication layer.

Implementation mistakes that weaken them

These controls fail when they are present in name only. Reusing a predictable state value, accepting a nonce but not validating it, or generating PKCE challenges incorrectly can leave the flow effectively exposed to the same threats it was meant to block.

Teams also weaken them by treating them as optional UI glue rather than security requirements. The controls need to be generated per transaction, preserved correctly across redirects, and verified before the client trusts the response or exchanges the code.

In practice, the biggest risk is partial adoption: one component validates state while another ignores nonce, or the authorization server supports PKCE but the client omits it for some flows. Consistency across all clients and all login paths matters more than isolated support.

Risk and Threat Considerations

These controls are a direct response to real OAuth abuse patterns. When they are missing or mis-implemented, attackers can exploit intercepted codes, forged callbacks, and replayed responses to gain unauthorized access or to complete a login as a different session than the one the user intended.

Failure mechanism: An attacker or malicious intermediary exploits weak redirect handling, code interception, or token replay to substitute a different authorization result, then uses the accepted response to obtain access or impersonate the intended login transaction.

Impact: The consequence can be unauthorized account access, session confusion, token theft becoming reusable access, or a successful login flow that authenticates the wrong user context.

Practitioner Guidance

Why practitioners should care: Treat state, nonce, and PKCE as separate checks with different failure modes, not as interchangeable hardening. If one is missing, the remaining controls do not fully compensate for the gap.

Common misunderstanding: PKCE is not a replacement for state, and state does not replace nonce in OpenID Connect. Each control answers a different trust question in the flow, so removing one usually changes the threat model rather than just reducing defense in depth.

Practitioner takeaway: Validate each value strictly, bind it to the exact transaction that created it, and reject any callback or token response that does not match the expected flow.

Related resources from NHI Mgmt Group

• Guide: OAuth 2.0 and OpenID Connect Guide for Identity Teams
• How should security teams implement state, nonce, and PKCE together in OIDC flows?
• Why do OAuth and OIDC flows need both nonce and PKCE if the code exchange already uses TLS?
• OAuth Connected App
• How should security teams implement PKCE across OAuth clients?