English

multi-tenancy
saas
organization
collaboration
identity
access control

Logto's multi-tenancy model explained

Take a look at how we designed Logto's multi-tenancy model and the benefits it brings to SaaS apps.

Gao

Founder

11/29/20233 min read

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

The confusion

You may have heard of some products that use the term "multi-tenancy" to represent the identity isolation: each tenant has its own set of users, roles, permissions, and data.

It may be counterintuitive, but in fact, "multi-tenancy" indicates the contrary: multiple tenants are sharing resources in a single instance. To users, an identity in an app is like a driver's license. For example, with one driver's license, you can drive in different states (one identity for multiple organizations), instead of applying for a new driver's license for each state.

Logto's model

At Logto, we noticed this confusion at the beginning of our design, and we urged to make it right for your apps and your users. Here's our design:

A tenant can be treated as a single Logto instance, which has its own set of users, permissions, and data.
Inside a tenant, it may have multiple organizations. A user can be a member of multiple organizations.
For each organization, it follows the role-based access control pattern (RBAC) and uses the same set of organization roles and organization permissions. The set is called organization template.
The organization roles and organization permissions are effective if and only if in the context of an organization.
- For example, a user can be an "admin" (role) in one organization, but a "member" (role) in another organization.
- Without the context of an organization, organization roles and organization permissions are meaningless.
Use organization permissions to control access in an organization, instead of using organization roles.

This model provides the flexibility and reusability for managing identities, especially for SaaS apps. If we take a look at some popular SaaS apps, we can find that they can all fit into this model. The term "organization" may be different in different apps, such as "workspace", "team", etc. But the concept is the same.

For example, in Notion (a popular collaboration tool):

You can create and join multiple workspaces with one account, instead of sign up for each workspace with different accounts.
For each workspace, Notion defines a same set of access levels: "Worksapce owner" and "member", while you may expect different access levels for different workspaces.

Hence, users can easily switch between workspaces without switching accounts or re-signing in, and it keeps the isolation between workspaces. Translate this to Logto's model, it means:

Organization template defines two roles: "owner" and "member".
If a user joined a workspace, it means the user is a member of an organization, and they has the "member" role in the organization.
If a user created a workspace, it means the user is a member of an organization, and they has the "owner" role in the organization.

According to different roles, a user can have different permissions in different workspaces (organizations).

The benefits

User experience

For users, they can enjoy the true single sign-on experience. Switching between organizations is as easy as switching between tabs.

Reusability

One advantage of SaaS apps is that they are standardized and scalable. For example, you can create a new workspace in Notion with a few clicks, and it is ready to use.

When your app is growing, you may want to add more roles and permissions to each organization. For example, a new role "guest" and a new permission "invite:guest". It can be a nightmare if you need to update all existing organizations one by one.

With Logto, you can update the organization template, and all existing organizations will be updated automatically.

One access control model, multiple use cases

In Logto, we use the same access control model (RBAC) for both organizations and API resources. It means that you don't need to learn a new access control model if you are familiar with RBAC. Meanwhile, they are isolated from each other, so you can use them for different use cases.

The most exciting part is that you can use them at the same time. Let's extend the Notion example:

For accessing workspaces, you can use Logto organization RBAC.
For accessing and updating account-level resources (such as profile and billing information), you can use Logto API resource RBAC.

Most of Logto SDKs support both types of RBAC.

The differences

Organization RBAC and API resource RBAC are different in the following aspects:

Organization RBAC requires the context of an organization, while API resource RBAC does not.
Organization RBAC is used to control access in an organization, while API resource RBAC is used to control access to API resources.
A user can have different organization roles in different organizations, while the roles for API resource are universal in the tenant.
Roles and permissions are isolated for these two types of RBAC.

Closing notes

Building a SaaS app is hard, and we hope Logto can help you focus on your core business. Don't hesitate to give us feedback if you have any questions or suggestions.

Try Logto Cloud for free

The confusion#

Logto's model#

The benefits#

User experience#

Reusability#

One access control model, multiple use cases#

Closing notes#

The confusion#

Logto's model#

The benefits#

User experience#

Reusability#

One access control model, multiple use cases#

Closing notes#

The confusion

Logto's model

The benefits

User experience

Reusability

One access control model, multiple use cases

Closing notes

The confusion

Logto's model

The benefits

User experience

Reusability

One access control model, multiple use cases

Closing notes