important

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

Handling statically and dynamically configured provider list

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-12-08

Context and Problem Statement#

Since we now allow users to dynamically add thirdparty provider configurations into the core, and also the user might have configured a static list of thirdparty providers in the code, this causes an ambiguity on what the final set of providers list should be, for the SDK to use.

How do we come up with a consolidated list of providers?

Considered Options#

Union of the list from core and the static config
Prioritize list from the core if not empty, else static list

Decision Outcome#

Chosen option: Prioritize list from the core if not empty, else static list, because

Gives complete control on the provider list for each tenant
Allows declaration in the static list for overrides, even if not used for all the tenants

Pros and Cons of the Options#

Union of the list from core and the static config#

Cannot hide a provider for a specific tenant if statically declared

Prioritize list from the core if not empty, else static list#

SDK would use the thirdparty provider list from the core if it is not empty, else, the statically configured provider list.

note

When a tenant is created on the core, the provider list would be empty. This would mean that the statically configured list would be used by default for that tenant.
If the user wants to disable the thirdparty entirely, they can use the createOrUpdateTenant core API to disable the thirdparty recipe

Gives complete control on the provider list for each tenant

Allows declaration in the static list for overrides, even if not used for all the tenants

Difficult to communicate to the user

Provider must be added to core as well, even if statically declared

Examples#

Assuming Builtin providers = ["apple (bultin)", "google (builtin)", "facebook (builtin)"]


* Case 1
  Static List = []
  Core List   = ["apple", "google"]
  Final List  = ["apple (builtin)", "google (builtin)"]

* Case 2
  Static List = ["apple", "google"]
  Core List   = []
  Final List  = ["apple", "google"]

* Case 3
  Static List = ["apple", "google", "facebook"]
  Core List   = ["apple", "google"]
  Final List  = ["apple", "google"]

* Case 4
  Static List = ["apple", "google"]
  Core List   = ["google", "facebook"]
  Final List  = ["google", "facebook (builtin)"]

* Case 5
  Static List = ["apple"]
  Core List   = ["google", "facebook"]
  Final List  = ["google (builtin)", "facebook (builtin)"]

Further details#

When a provider is statically declared in the code and the same provider is configured in the core, the SDK would merge each property prioritizing the values from the core.

This is not applicable for the clients list, and is merged as discussed here.

Even if the provider is not in the static list, but is a built-in provider in the SDK (like apple, AD, google, etc.), we would use that providers implementation and then merge the core config on top of that as if the user had added it to the static list.

Config merging example#

For a particular provider, if the statically declared config is:

{
  thirdPartyId: "custom",
  authorisationEndpoint: 'example.com/authorise',
  tokenEndpoint: 'example.com/token',
}

and for a particular tenant, the config stored in the core is:

{
  thirdPartyId: "custom",
  authorisationEndpoint: "anotherexample.com/authorise",
}

The final config used by the SDK would be:

{
  thirdPartyId: "custom",
  authorisationEndpoint: "anotherexample.com/authorise",
  tokenEndpoint: 'example.com/token',
}