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.

Support non-deprecated flows in rfc6749 + PKCE

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#

The OAuth2 docs/rfcs contain a lot of different grant types/flows, we need to decide to which to implement. There are a few groups I'd like to consider:

  • OAuth2.0 (the ones defined in rfc6749) grant types: Authorization Code, Implicit, Resource Owner Password Credentials, Client Credentials
  • Refresh token (defined in rfc6749, but not as a grant type)
  • Authorization Code w/ PKCE (not defined in rfc6749)
  • Other extension grant type (e.g.: Device code)

Considered Options#

  • All flows
  • Only OAuth2.0 flows (rfc6749)
  • Non-deprecated flows in rfc6749 + PKCE

Decision Outcome#

Chosen option: Non-deprecated flows in rfc6749 + PKCE, because

  • It needs the least amount of work we need to cover our main
  • We can disable deprecated flows/grant_types (protecting our users)

Pros and Cons of the Options#

All flows#

  • Supports all possible use-cases
  • A lot of work upfront
  • Supports niche and/or irrelevant usecases
  • Easy to add support for new flows later

    • Only OAuth2.0 flows#

  • Well defined scope - implements a single rfc
  • Contains deprecated and unsecure flows
  • Doesn't cover the recommended solution for SPAs and mobile apps (so most of our usecases)

    • Non-deprecated flows in rfc6749 + PKCE#

  • Covers recommended flows for our usecases
  • We can disable deprecated flows/grant_types (protecting our users)
  • Least amount of work we need to cover our main usecases
  • We may need extra docs to explain what/why we support
    • Which UI do you use?
    Custom UI
    Pre built UI