Skip to main content
important

This is a contributors guide and NOT a user guide. Please visit these docs if you are using or evaluating SuperTokens.

Introduce a new setting to expose entire access token to FE

Status

This is just a proposal so far, it hasn't been accepted and needs further discussion.

Status:
proposed
Deciders:
rishabhpoddar, porcellus
Proposed by:
porcellus
Created:
2022-12-06
Last updated:
2023-01-02

Context and Problem Statement#

In the SSR + accessing access token on the frontend (i.e.: websocket) usecase, the user may want to access the entire access token on the FE, but also needs the BE to access them during SSR. To access them on the FE we'd have to use header based auth, but that'd mean that the BE wouldn't have access to it during SSR.

Considered Options#

  • Use header-based auth and set cookies for auth on the FE
  • Always set cookies (even in header mode)
  • Introduce a new auth mode
  • Introduce a new setting (exposeAccessTokenToFrontendInCookieBasedAuth)

Decision Outcome#

Introduce a new setting that will send the access token to the frontend even if using cookie based auth.

  • We can use the header we are already using during header based auth
  • This will be automatically saved by the FE SDK, we only need to change when the auth header is added (only if both refresh and acces token is present)
  • We need to add a new function to make it accessible. (this will work for both header based auth and explicitly exposed access tokens)
  • Mention this in web-socket docs
  • This should also be set to true by the legacy jwt: {enable: true } setting.
  • We should mention this in the handling session tokens sections of each recipe (search for getAccessToken in docs)

Pros and Cons of the Options#

Use header-based auth and set cookies for auth on the FE#

  • No new auth-mode
  • Harder to use in the SSR+JWT use-case
  • Always set cookies (even in header mode)#

  • Easy to use in the SSR+JWT use-case
  • No new auth-mode
  • Counter-intuitive: we are still using cookies even if config tells us to use headers only
  • Forces a setting of a fairly niche use-case on everyone
  • Introduce a new auth mode (header + cookie)#

  • Easy to use in the SSR+JWT use-case
  • New auth-mode/docs
  • Makes both tokens available on the FE
  • Non-obvious choice: the user may just want the access token available on the FE without using it for authentication on the same BE (e.g.: uses it only for other serverless APIs)
  • Introduce a new setting#

  • Easy to use in the SSR+JWT use-case
  • Very specific setting to make the access token available on the FE
  • Easy to explain
  • Only exposes the access token to the frontend
  • Ignored during header based auth (we could add a warning, but it'd only show up when a session is created)
  • Complicates implementation when updating/saving sessions