Multi-Tenant Applications Best Practices
Multi-tenancy is an architectural approach featuring a single instance of software that runs on a server and is accessible by multiple groups of users. With multi-tenancy, you can segment users with shared characteristics into groups and grant them separate permissions and levels of access to your application. This allows you to create and maintain tailored experiences for different customers, business units, or other defined groups of users.
In Auth0, the best method for implementing multi-tenancy is Auth0 Organizations. If necessary, other legacy solutions can be used to accommodate distinct business use cases. If you offer a business-to-business (B2B) product or service, setting up multi-tenancy for your business users may be beneficial for your use case.
The sections below outline the options available for implementing multi-tenancy in Auth0.
This article uses the software architecture term "tenant" to refer to a group of users who can access your application. When referring to your Auth0 instance, the term "Auth0 tenant" is used.
Auth0 Organizations
For most multi-tenant use cases, Auth0 Organizations is the ideal solution for you and your users. Auth0 Organizations supports business-to-business (B2B) implementations that have one or more applications that end-users can access.
Common features of B2B implementations include:
A product that is licensed to another business for use by their employees.
Multiple organizations that require their own federation and lightweight branding of the authentication experience.
Separate levels of application access for different groups of users.
With Auth0 Organizations, you can create unique groups of users and tailor their experiences with role-based access control, customized login pages and email templates, and more.
To learn more about using Auth0 Organizations to implement multi-tenancy, review Multiple Organization Architecture.
Legacy solutions
If Auth0 Organizations does not satisfy the requirements of your use case, please reach out to our Professional Services team to develop a solution that ensures your success.
Some legacy solutions include:
Using an Auth0 connection to represent each tenant.
Using an Auth0 application to represent each tenant.
Using an Auth0 tenant to represent each tenant.
Storing tenant details in the user's profile.
Use Auth0 connections
Entity limits may apply. To learn more, read Entity Limit Policy. If you have an Enterprise subscription, you will not be constrained due to entity limits, but you may be constrained by a connection that already has thousands of enabled clients.
You can represent each of your tenants with a separate Auth0 connection.
This approach allows you to support scenarios where:
You have different connection-level requirements, such as varying password policies, for each of your tenants.
You have user pools from different connections. For example, one tenant could require users to provide username/password credentials, while another tenant could require users to log in through an enterprise IdP.
To prompt a user to log in through a specific connection, call the Auth0 Authentication API Login endpoint, and include the connection parameter.
If you use Lock in your application, note that it supports a maximum of 50 database connections per application. Social and enterprise connections are not affected by this limit, but are still subject to the Entity Limit Policy.
Use Auth0 applications
Entity limits may apply. To learn more, read Entity Limit Policy. If you have an Enterprise subscription, you will not be constrained due to entity limits, but you may be constrained by a connection that already has thousands of enabled clients.
You can represent each of your tenants with a separate Auth0 application.
This approach allows you to uniquely configure each Auth0 application based on varying tenant requirements, such as available connections.
You'll need to track the tenants to which your users belong within your application. When a logs into your application, you'll need to read that information, and direct the user to the appropriate Auth0 application to complete authentication.
To enable a connection for multiple applications with the Auth0 Management API, call the Update a Connection endpoint, and pass the relevant Client IDs to the enabled_clients parameter.
Use Auth0 tenants
You can represent each of your tenants with a separate Auth0 tenant.
This approach allows you to share access to the Auth0 Dashboard with users, restricted by tenant, but requires you to configure Auth0 individually for each tenant.
This means that, in addition to managing the features of each Auth0 tenant individually (such as Branding, Actions, and Attack Protection), your application will have to support multiple Auth0 configurations.
Store tenant details in the user's profile
You can store tenant details in the user's profile and have your application read that information after the user logs in.
This approach allows all of your users, regardless of which tenant to which they belong to, to log in using in a uniform configuration (such as available connections).
To implement this, you could store tenant details in the user's Auth0 profile in the app_metadata object, using an identifier of your choice (for example, "tenant": "customer-group-12345"). After the user logs in, your application retrieves the tenant variable, and then displays a version appropriate to the returned value.