OpenIdConnect nonce vs code verifier storage

[maciejsobocinski]

Looking at the OpenIdConnectHandler implementation the "state" passed through to the idp is an encrypted value containing amongst other things the pkce code_verifier later used to exchange code for tokens, and a correlation id also stored in cookie and used to prevent csrf. What I'm trying to understand is why is the "nonce" stored in a whole separate cookie VS passing it inside of the encrypted state so it can be read back on the callback (given that is how the code_verifier is passed through)? Is there any security implications in embedding the nonce into encrypted state?

[MentalOfCrow]

They protect different things, and the separate cookie is how this handler gives the OIDC nonce an independent, browser-bound, one-time lifecycle.

Value	What it protects	What it is checked against
PKCE code_verifier	interception/redeeming of the authorization code	the code_challenge bound to the code at the authorization server
OIDC nonce	association of the ID token with this login attempt, plus ID-token replay	the nonce claim in the returned ID token
correlation value / state	the remote-authentication round trip (CSRF/session correlation)	protected AuthenticationProperties plus the correlation cookie

In ASP.NET Core's current OpenIdConnectHandler, the PKCE verifier is put in AuthenticationProperties, which is then protected into state. It is retrieved only when the authorization code is redeemed.

The nonce takes another path:

1. the handler generates it and calls WriteNonceCookie;
2. the protected nonce is encoded in the cookie name and the cookie value is just N;
3. on the callback, it reads the nonce claim from the ID token, finds and unprotects the matching cookie, deletes that cookie, and gives the value to OpenIdConnectProtocolValidator;
4. that same mechanism works whether the ID token arrives in the authorization response (hybrid/implicit) or from the token endpoint (code flow).

This follows the OIDC requirement that, when a nonce was sent, the ID token must contain the same value and the client should detect replay. The spec deliberately leaves the storage method to the client; its implementation notes explicitly suggest a cryptographically random HttpOnly session cookie for a web client: OIDC Core, nonce validation and implementation notes. PKCE has a different protocol role, described in RFC 7636: the verifier proves possession when redeeming the authorization code.

Could a different implementation carry nonce-related state inside a protected state value? Yes—the OIDC spec does not mandate a cookie. But it would still need sufficient entropy, expiration, binding to the initiating browser/session, constant-time comparison where appropriate, and one-time/replay handling. Merely round-tripping the value in a self-contained state token and comparing it to the ID-token claim would not by itself provide the same independent browser-possession and consume-on-read behavior.

So the separate cookie is not evidence that protected state is considered unsafe. It is a deliberate separation of three controls with different purposes and lifecycles. I would not customize the handler solely to merge them; if the nonce cookie is causing a practical issue, it is safer to fix the HTTPS/proxy/SameSite or cookie-limit problem than to disable or weaken nonce validation.

If this answers the design question, please mark it as the accepted answer so future readers can find it quickly.