Using Auth0 with Multi-Tenant Applications
Multi-tenancy refers to the software architecture principle where a single instance of software runs on a server that is accessible to multiple groups of users.
When working with multi-tenant software, you can serve multiple customers from a single application instance running on one server (or pool of servers). This contrasts with single-tenant software, where you serve each customer with a dedicated software instance running on dedicated servers. In summation:
|Multi-Tenant||One instance, multiple customers|
|Single-Tenant||One instance, one customer|
We define tenant as a group of users who share access to one particular application instance. One example of this includes a company with multiple employees, all of whom have access to your SaaS offering.
When you use a multi-tenant setup, one single instance of your SaaS offering would be shared across multiple tenants (or multiple companies), each of whom has its own group of employees. However, each tenant has a dedicated share of that instance, and you can then customize each share to meet the needs of the tenant that's using it. Such customization includes (but isn't limited to) branding, functionality, and access control.
Auth0 and Multi-Tenancy
By using a single Auth0 tenant for all of your customers, you maintain simplicity in your architecture and are able to manage all of your authentication flows in one place. The primary method by which you can handle multi-tenancy is to use multiple connections.
Use Multiple Connections
While using multiple Connections introduces additional layers of complexity, there are several scenarios where this option might make sense:
- You have different Connection-level requirements, such as varying password policies, for each of your Clients.
- You have users from different Connections. For example, one app may have users providing username/password credentials, while another app handles Enterprise logins.