important
This is a contributors guide and NOT a user guide. Please visit these docs if you are using or evaluating SuperTokens.
supertokens-auth-reactUsing 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 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