What Is Multi-Tenancy?
A multi-tenanted software architecture allows you to serve multiple customers from a single application instance running on a single server, or pool of servers. This is in contrast to a single-tenant application where each customer would have a dedicated software instance running on dedicated servers. Thus,
- Multi-tenant: One instance, multiple customers.
- Single-tenant: One instance, one customer.
A tenant is defined as a group of users who share access to that application instance. For instance, this could be a company with multiple employees, all who have access to your SaaS service. In a multi-tenant architecture, a single instance of your application would be shared across multiple companies (tenants), and across multiple employees within those companies.
Every tenant would however have a dedicated share of that instance, and multi-tenant application can then be customized for each specific tenant's need, in particular:
- Branding: Each instance would likely need to be “skinned” to fit with the branding of the organization. This is akin to how Lock can be customized for each user's login page.
- Functionality: Each tenant may require certain workflow changes that fit better with their business.
- Access Control: Each tenant will want to set the permissions, rights, and roles of their users independently.
The Benefits of Multi-Tenancy
Building multi-tenant applications conveys a number of benefits for a SaaS company:
Scalability: There is overhead associated with spooling up each application instance. Extra processing power and memory is required over and above just that for the single instance. Additionally, resources can be shared across tenants in a multi-tenant architecture.
For example, if a SaaS company had 10 tenants, and each tenant needed just over 1 server to fulfill their requirements (say, 1.1 servers), in a single-tenant architecture this would require 20 servers as each tenant would need dedicated servers. In multi-tenant architectures, only 11 servers are needed, as resources can be shared easier.
Data Handling: It is easier for the SaaS company to handle and utilize data when it is aggregated in a single location. In a single-tenant application, data will be spread across multiple databases and will need to be pooled for any further analysis by the SaaS. In multi-tenant, this data is easily available, so running queries across multiple tenants and analyzing trends is simpler.
Release Management: In a multi-tenant application, there is just one codebase running on a single server or pool of servers. When a fix has to be implemented to the codebase, it just has to be rolled out to this single instance and there is no need to update multiple servers or locations. For a single-tenant application, each instance will need to be patched independently, and tests run on each.
Why Multi-Tenancy Is Difficult
Building multi-tenant applications is a challenge as it requires significant planning and forethought to go into the initial coding. As there is no physical separation between different tenants like there would be with single-tenant architectures, all the separation has to be resolved in code. Developers have to:
- determine the tenant a request was intended for
- protect against data leakage
- isolate configurations
- run individual logging and background tasks per tenant
Additionally, as each tenant’s data is stored together, significant security testing is required to make sure each tenant has access to only their data.
Using Auth0 To Build A Multi-Tenant App
Authentication and authorization are fundamental to multi-tenant architectures. Correctly authenticating individual users within a tenant organization and determining what they are authorized to access are paramount to this software model.
"Authentication and authorization are fundamental to multi-tenant architectures."
Tweet This
Learn more about how to use multi-tenant applications within Auth0 in the following link: Using Auth0 with Multi-tenant Apps.
You can use the Auth0 API to authenticate and authorize users for each application easily:
- Authenticate users established by their email address. This could either be through custom email/password combinations with a rule set up to determine the tenant via company email (home realm discovery), or via identity federation such as LDAP, Active Directory, or custom SAML providers.
- Authorize users by assigning different roles within the company. This would be managed through metadata.
Metadata in an Auth0 user profile allows you to associate specific information to any authenticated user. In the user profile, Permissions, Groups, and Roles are all special cases of these attributes.
For instance, a user might be authenticated for multiple tenants and have different roles in those tenants:
{
"email": "matias@auth0.com",
"app_metadata" : {
"permissions" : {
"auth0" : {
"role" : "admin",
},
"sharelock" : {
"role": "user",
}
}
}
}The logic of the applications can then use this metadata to restrict or allow users access to data and instances as the roles allow.
Unlock B2B SaaS growth with modern identity management. Download free eBook here.
