This is a paid feature. For self hosted users, Sign up to get a license key and follow the instructions sent to you by email. This will start a SuperTokens subscription.
If you are using the development environment of our managed service you can use this feature for free. If you want to enable this feature for the production environment, please email us
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
customer2 hosted on
customer2.yourdomain.com can have login with
This is also the page that you should see if you want to implement sign in with:
- Okta (
- SAML (
- Active Directory (
- Google Workspaces (
- GitLab (
- Bitbucket (
- Or any other workforce IdP
- 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 your customers 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 during customer onboarding.
Each tenant can have its own login method. For example, one tenant can have email password login, while another can have SSO login.
Each tenant will have its own user pool.
- Isolating users to their orgnisation becomes very simple.
- This also means that one user can login using the same email across different tenants and they will be treated as different users. You can also share a user across tenants.
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.
You can create and configure a tenant via few, simple API calls from your backend API layer. No need to manually onboard customers anymore.
Create multiple dev / staging environments to help with your development process. You can also create a new environment on the fly for CICD testing purposes.
Use any form of tenant discovery method. For example, use one sub domain per tenant, or a form for tenant selection. The form can have a list of tenants to choose from, or an input box to enter the tenantId / workspace URL / identifier - as defined by you.
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
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.