Paid Feature
This is a paid feature. Email us to get a license key to start a SuperTokens subscription.
If you want to try this feature without contacting us, you can sign up for our managed service, and use this feature in our development environment for free.
Multitenant 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 email password (using this recipe), and another customer customer2
hosted on customer2.yourdomain.com
can have login with Active Directory
and Facebook
(using the thirdparty recipe).
#
Features#
Different user poolsEach 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.
#
Data isolationIn 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.
#
Dynamic tenant creationYou can create and configure a tenant via few, simple API calls from your backend API layer. No need to manually onboard customers anymore.
#
Multiple dev environmentsCreate multiple dev / staging environments to help with your development process. You can also create a new environment on the fly for CICD testing purposes.
#
Types of UX flowsIn 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.