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.

Auth method chosen by frontend preference and backend validation

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-10-25

Context and Problem Statement#

We have to decide which auth method (header or cookies) to use when creating/verifying/refreshing sessions for each request.

Considered Options#

  • Configured on the backend
  • Configured on both
  • Configured only on the frontend and sent along the request
  • Preference set set on the frontend and controlled by the backend

Decision Outcome#

Preference set on the frontend (and sent with request) and validated by the backend.

  • By default the backend respects the preference, but can be configured to ignore it.

Pros and Cons of the Options#

Configured on the backend#

  • Configured only in a single place
  • Configuration would be hard for users
  • Hard to set separate values per FE (we'd have to rely on user-agents)
  • Configured on both (with a simple value)#

  • Double the configuration
  • Chance for mismatching configs
  • Hard to set separate values per FE
  • Very explicit
  • Configured only on the frontend and sent along the request#

  • Configured only in a single place
  • Easy to set separate configs per FE
  • Less secure, an attacker could force the less secure header option through XSS then steal the tokens
  • Preference set on the frontend (and sent with request) and validated (or controlled) by the backend#

  • Configuration overall neutral:
    • configuration in two places
    • Default on the backend will fit almost all use-cases)
    • The configuration is not really duplicated
  • Easy to set separate options per FE
  • More secure: the backend can be configured to deny header based auth