oauth2-redirect-verifier value #1079

Activity

1. alexdigdir

   added

   help wantedExtra attention is neededExtra attention is needed

   on Feb 6, 2025
2. alexdigdir

   changed the title [-]Help[/-] [+]oauth2-redirect-verifier value[/+] on Feb 6, 2025
3. metcoder95 commented on Feb 7, 2025

   

   metcoder95

   on Feb 7, 2025

   Member

   More actions

   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?
4. alexdigdir commented on Feb 7, 2025

   

   alexdigdir

   on Feb 7, 2025

   Author

   More actions

   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?
5. metcoder95 commented on Feb 9, 2025

   

   metcoder95

   on Feb 9, 2025

   Member

   More actions

   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.