When storing PKCE code_verifier in session cookie, must it be encrypted, or is it enough for it to be signed?

[lpsinger]

According to the Authorization Code Flow example in the README, you should "store the code_verifier in your framework's session mechanism, if it is a cookie based solution it should be httpOnly (not readable by javascript) and encrypted."

Is it necessary for it to be encrypted, or is it sufficient if it is simply signed? My framework signs session cookies, but I don't believe it encrypts them. (In my case, the framework in question is Remix.)

[alxndrsn]

Hi @panva, resurrecting this thread to add a bit more context to the question, as I'm trying to understand safe handling of code_verifier values via cookies.

The openid-client v5 README reads as in the above question (emphasis mine):

store the code_verifier in your framework's session mechanism, if it is a cookie based solution it should be httpOnly (not readable by javascript) and encrypted.
—https://github.com/panva/openid-client/tree/v5.x?tab=readme-ov-file#authorization-code-flow

However, this advice seems to have been weakened in the v6 README:

You must store the code_verifier and state in the end-user session such that it can be recovered as the user gets redirected from the authorization server back to your application.
—https://github.com/panva/openid-client/tree/main?tab=readme-ov-file#authorization-code-flow

In 2021 you recommended:

a separate httpOnly; attribute tamper-proof cookie
—#373 (comment)

Then again, last week (2024) you said:

Yeah, an encrypted serialized session cookie or a regular backend stored session with an identifier in a cookie...
—#706 (reply in thread)

"Encrypted" is unambiguous advice, but as in the question above, "tamper-proof" could mean a signed cookie (as is common with e.g. expressJS's request.signedCookies, or perhaps just httpOnly(? maybe this would only qualify as "tamper-resistant".)

In addition to this, signing the code_verifier would only seem to protect against its value being guessed, rather than the cookie being stolen, and this seems unlikely if generators.codeVerifier()/client.randomPKCECodeVerifier() is used as the source.

What are the risks of sharing a non-encrypted code_verifier via cookie?

[panva]

It really depends on the type of client - confidential or public, and also where it runs - server, user-agent, device.

A public client running in browser can't obviously do httpOnly; a cookie, it can however encrypt using webcrypto using a non-extractable key, the encryption however doesn't change the protection much because if the client happens to embed malicious scripts they can get to the non-extractable key reference stored (can only be stored in IndexedDB) as well.

A server side client must always do an httpOnly; cookie, and then it depends on whether it only stores the verifier or whether there's other state information stored too, in the latter case it should at least be signed, but you might as well do AEAD symmetric encryption instead. Signing or encrypting just the pseudo random value itself doesn't bring in much but doesn't hurt either.