Multi-Tenant Applications Best Practices

Multi-tenancy is when a single instance of software runs on a server that is accessible to multiple groups of users. To learn more, read Multitenancy on Wikipedia.

For most multi-tenant use cases, Auth0 Organizations is the best option to support you and your users.

Auth0 Organizations supports business-to-business (B2B) implementations that have applications that end-users access.

Common features of B2B implementations include:

• A product that is licensed to another business for use by their employees.

• Each organization requires its own federation and lightweight branding of the authentication experience.

• Access levels in the application can be represented by roles that are assigned to members of each organization.

For more information about using Organizations to support multi-tenant architectures, read Multiple Organization Architecture.

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.

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.

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.

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.

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.