oauth2-redirect-verifier value

[alexdigdir]

💬 Question here

I am a bit concerned about potential security issues and so I am wondering if the "oauth2-code-verifier" is the hashed version (code challenge) of the plain text Code Verifier?

It it IS hashed, I guess there is no security issue...?
If it is NOT hashed, then it seems like it does not fulfill Oauth2 protocol...? (Im not claiming necessarily, Im asking)
Ref.:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-authorization-code-grant

Your Environment

• node version: 22
• fastify version: 7.8.0
• os: Linux (docker container running on Mac)

[metcoder95]

Hi @alexdigdir, I'm not fully understanding what are you asking exactly.
Are you seeking to know if the oauth2-redirect-verifier value has potential security issues?

Can you elaborate what exactly are you asking for?

[alexdigdir]

Hey @metcoder95

Certaintly!

We have a SPA with a backend-for-frontend (BFF) that acts as an OAuth2 client, translating the OIDC provider’s ID token into a session (via cookies) between the BFF (/api/*) and the SPA.
Currently, we use @fastify/session with @fastify/oauth2 and @fastify/cookie, but there's an issue:
Flow:

1. The SPA checks authentication via the BFF. If unauthenticated, it redirects to the BFF’s login route (startRedirectPath in OAuthPluginOptions).
2. The user is redirected to the OIDC provider for login.
3. On success, the OIDC provider redirects to callbackUri (BFF), which:

• Extracts the token via getAccessTokenFromAuthorizationCodeFlow
• Stores it in the session (@fastify/session + connect-redis)
• Redirects the user back to the SPA with a session cookie

However, oauth2-code-verifier and oauth2-redirect-state are also set, raising concerns about potential security risks. If they are only needed between the BFF and SPA, we may be able to remove them.
Given this setup, should we be using @fastify/secure-session instead of @fastify/session for what we are trying to achieve here?

[metcoder95]

There should not be big major concerns towards these headers as they are used for session management rather than actual exchange of the information.

By default they are set as httpOnly, which will cause browsers to not make it accessible to your SPA.

If your SPA does not requires cross site cookie sharing, setting the sameSite: 'Strict' will cause the browser to hint the browser only sent back all these cookies if request are sent to the same origin of your SPA.

Wether use secure-session or session depends on the level of management you want on your session state. I'd recommend to always seek for secure-session unless strict requirement of otherwise.