Paid Feature

This is a paid feature. Email us to get a license key to start a SuperTokens subscription.

If you do not wish to pay, you can override the recipe functions of the Multitenancy recipe on the backend to save / read information from your database instead of calling the SuperTokens core.

Multitenant and Enterprise SSO login

Multitenant login is a feature that lets you customize the login experience for each of your customers. For example, a customer customer1 hosted on customer1.yourdomain.com can have login with Active Directory and Google, and another customer customer2 hosted on customer2.yourdomain.com can have login with Okta and Facebook.

This is also the page that you should see if you want to implement sign in with:

Okta (thirdPartyId: "okta")
SAML (thirdPartyId: "boxy-saml")
Active Directory (thirdPartyId: "active-directory")
Google Workspaces (thirdPartyId: "google-workspaces")
Or any other workforce IdP

Features#

Enterprise SSO#

Allows your customers to login using their Workforce IdP (OAuth 2.0 & SAML supported). The list of in built providers is stated above, but you can also easily define a custom provider in case we don't support it out of the box.

Allow tenants to set thier own SSO provider dynamically#

You may want to allow your tenants to add and configure their SSO provider themselves. SuperTokens gives you all the building blocks required for this so that you can let customers add their own SSO provider with zero manual intervention from your side.

Data isolation#

In addition to the above, this feature can also be used to implement data isolation for each of your tenants wherein a different database is used per tenant.

Types of UX flows#

In this section, we will explore how to implement different forms of multi tenant login experiences:

Tenants use a common domain to login: All tenants login using the same page (for example, example.com/auth) and are optionally redirected to their sub domain post login. At the start of the login flow, the customer will have to input their tenantId / workspace URL / identifier - as defined by you, and the login methods shown would be based on their tenantId.
Tenants use their sub domain to login: Here, each tenant has a sub domain assigned to them (for example customer1.example.com, customer2.example.com, ...), and they would visit their sub domain to login and access their app. Each sub domain's login experience may be different (as defined by you or the tenant).

SuperTokens is flexible enough to allow other forms of UX as well, but since the above two flow are most common, we provide dedicated docs for them.