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.

Showing thirdparty provider list dynamically

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-07

Context and Problem Statement#

Context#

We would like to allow users to show the list of thirdparty providers dynamically. This means that the user should be able to add, update or delete providers without having to change the code. In the case of multi-tenancy, the user should be able to show different providers for different tenants.

This is in the context of thirdparty recipe, however when we expand the multi-tenancy functionality to other recipes, we should be able to dynamically determine different login methods (emailpassword, thirdparty, etc) for each tenant.

From the above context, we have 4 different use cases:

  1. Static Config and single tenant
  2. Static Config and multiple tenants
  3. Dynamic config and single tenant
  4. Dynamic config and multi tenant

Clearly, for the use cases 3 & 4, we need to fetch the list of providers from the backend.

Use cases explained#

1. Static Config and single tenant

This is a very basic use case where the user has a single tenant and statically configured list of login methods and thirdparty providers.

2. Static Config and multiple tenants

In this case, the user uses the same set of statically configured login methods and thirdparty providers across all tenants.

3. Dynamic config and single tenant

In this scenario, although the user has a single tenant, he may need to add or remove thirdparty providers dynamically.

4. Dynamic config and multi tenant

This would be a classic multi-tenant scenario, where each tenant has a different set of thirdparty providers enabled, and different credentials for them.

Problem Statement#

What would be the best way for the user to differentiate & configure the SDK for all the above use cases?

Considered Options#

  • Show providers list dynamically when Multitenancy recipe is initialized
  • Always try to show providers list dynamically, fallback to statically configured list
  • Add usesDynamicLoginMethod config to each recipe
  • Add usesDynamicLoginMethods config to the top level config, defaulted to false
  • Add usesDynamicLoginMethods config to the top level config, defaulted to true if the user has provided implementation for getTenantId in Multitenancy.init(), else false

Decision Outcome#

Chosen option: Add usesDynamicLoginMethods config to the top level config, defaulted to false, because

  • Clearly indicates that the dynamic providers list is being used
  • Avoids call to backend if the user does not intend to use dynamic providers list, even if multi tenancy is initialised

Also, usesDynamicLoginMethods is added as a toplevel config instead of thirdparty recipe, as this will avoid multiple network calls in future while expanding this feature into other recipes.

This is how the user would configure the frontend in the mentioned use cases#

Single Tenant, static config

User does not need to set usesDynamicLoginMethods (false by default), nor do they they need to initialise multitenancy recipe.

Multi Tenant, static config

Frontend is initialized with Multitenancy.init() with a config to get tenantId. User does not need to set usesDynamicLoginMethods (false by default).

Single Tenant, dynamic config

Frontend is initialized with usesDynamicLoginMethods set to true. No multitenancy.init() required.

Multi Tenant, dynamic config

Frontend is initialized with usesDynamicLoginMethods set to true, and Multitenancy.init() with a config to get tenantId.

Pros and Cons of the Options#

Show providers list dynamically when Multitenancy recipe is initialized#

This means that whenever the login methods and thirdparty providers list has to be dynamically fetched from the backend, Multitenancy recipe must be initialized by the user.

  • From the user's point of view, it is unintuitive to call `Multitenancy.init()` for a single tenant / dynamic config use case
  • Always try to show providers list dynamically, fallback to statically configured list#

    Here, we always try to fetch the dynamic config from the backend. If the user has not configured in the core, the SDK would fallback to use the static configuration

  • No extra config needed by the user
  • Ends up calling the backend API unnecessarily if the static provider list is enough for the user
  • Add usesDynamicLoginMethod config to each recipe#

  • When using a combination of recipes, would need multiple calls to the Backend to fetch the dynamic config
  • Add usesDynamicLoginMethods config to the thirdparty recipe, defaulted to false#

  • Backend API will be called only when the feature is enabled
  • Clearly indicates that the dynamic providers list is being used
  • In case of multi-tenancy, even though it's most common to use dynamic provider list, user has to enable this to avail that functionality
  • Add usesDynamicLoginMethods config to the top level config, defaulted to true if the user has provided implementation for getTenantId in Multitenancy.init(), else false#

  • Handles common cases - [Single-tenant, static config] and [Multi-tenant, dynamic config] seamlessly with minimal config by the user
  • Difficult to implement
  • Difficult to communicate the option to the user