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.

Only store the hashed client secret

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#

Some other providers let you see the client secret multiple times.

Considered Options#

  • Only store the hash and not support viewing it later
  • Store the secrets as plaintext
  • Store the secrets encrypted
  • Store a prefix of the secret

Decision Outcome#

Chosen option: Only store the hash and not support viewing it later

  • Simple & Secure
  • We don't really have anything we can securely use to encrypt these secrets

Pros and Cons of the Options#

Only store the hash and not support viewing it later#

  • Secure
  • Simple
  • Doesn't support this usecase

    • Store the secrets as plaintext#

  • Simple
  • Huge security issues in case of a DB leak

    • Store the secrets encrypted#

  • No security issues in case of a DB leak
  • We don't really have anything we can securely use to encrypt these secrets

    • Store a prefix of the secret#

  • Provides partial support, it could serve as a way to identify secrets
  • In all usecases (I could think of) the secret is stored coupled with the id - making this feature less useful
  • In the usecase where both a secret and an id is available but the user suspects they do not match, they can check it using the token endpoint
  • Degrades the entropy if the client secret
    • Looking for older versions of the documentation?
    Which UI do you use?
    Custom UI
    Pre built UI