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.

Store the original query params creating the tokens/code

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:
2023-05-11

Context and Problem Statement#

To support certain OIDC features, we'd need to add new columns to the tokens/auth code table. One example is nonce using the authorization code flow:

  • we would need to reflect the nonce added to the request creating the auth code in the id token
  • the id token is created by the later tokens call in this flow by which time we do not have access to the original query params

Considered Options#

  • Add a separate column for each type of query param
  • Store the original query params creating the tokens/auth code

Decision Outcome#

Chosen option: Store the original query params creating the tokens/auth code

  • Simplifies Core implementation
  • Choosing to support new features later doesn't involve DB change

Further details#

  • A new column/prop is added into authorization codes and access tokens + related responses
  • This will contain all the query params that were used when creating the auth code - so only applicable for the auth code flow.
  • We give the query param string wherever we given back token info.
  • The format of the string will be param1=value1&param2=value2 (the core should check the format of this). We want to maintain the URL encoding on this string.

Pros and Cons of the Options#

Add a separate column for each type of query param#

  • No duplicate information stored
  • It could require future DB changes and/or adds potentially unused columns into the DB
  • Store the original query params creating the tokens/auth code#

  • Simplifies Core implementation
  • Choosing to support new features later doesn't involve DB change
  • Some information is stored twice - this is also solveable if necessary