important

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

Using ProviderInput instead of Provider.init() in the providers list for thirdparty.init

Status

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

Status:: proposed
Deciders:: rishabhpoddar, sattvikc
Proposed by:: sattvikc
Created:: 2022-10-25

Context and Problem Statement#

Currently the providers list in the thirdparty.init() is populated with the providers implementations using the appropriate provider.init() function, such as Google.init(), Facebook.init(), etc.

Instead, should we just accept the thirdparty config as a ProviderInput and then create implementations at runtime?

Proposed init would look like this (2nd option in the considered options):

thirdParty.init({
  signInUpFeature: {
    providers: [
      {
        thirdPartyId: "google",
        config: {
          clients: [
            { clientId: "...", clientSecret: "..." }
          ]
        }
      },
      {
        thirdPartyId: "custom",
        config: {
          clients: [
            { clientId: "...", clientSecret: "..." }
          ],
          authorisationEndpoint: 'custom.com/authorize',
          tokenEndpoint: 'custom.com/token',
        }
      }
    ]
  }
})

Considered Options#

Keep the existing way of using Provider.init()
Accept ProviderInput instead, with thirdPartyId specified

Decision Outcome#

Chosen option: Accept ProviderInput instead, with thirdPartyId specified, because

Avoids ambiguity in cases like user creating a custom provider with the same id as built-in ones.
Since the recipes are going to fetch the config from the core, to check if the recipe is enabled, at that point we can merge the provider configs from the core with the statically declared ones, so that within the implementation of the recipe APIs or the providers, we need not do additional steps to fetch config from the core.

Pros and Cons of the Options#

Keep the existing way of using Provider.init()#

Further details if necessary

Familiar for existing users

Creates ambiguity when user creates a custom provider with same id as built-in provider

Accept ProviderInput instead, with thirdPartyId specified#

Provider implementations will be created in runtime, and user will not be able to create ambiguous providers

Enables simplification of the API and provider implementations by doing the config merges before their execution