Do you really need multiple tenants to manage your identity system?
The concept of 'tenant' is relatively unfamiliar to most users, but it is especially important for building identity models. In this article, we will go through examples to help everyone understand what kind of identity model suits their business.
Developer
With the increasing maturity of low-code tools and cloud services today, accompanied by the acceleration of AI toolization, the threshold for developing apps is being greatly lowered, and more and more apps are appearing in the market.
Whether it's complex or simple apps, most apps involve user registration and login scenarios, so that users can get more stable, secure and customized services. And to solve the problem of user login and registration, the first step is to build an identity system.
For many consumer-facing apps, their identity models are often relatively simple, or even just require email and password. For apps that are in a stage of rapid growth and attracting new users, this is enough; but once the app has its own business model, in the simplest case, for example, serving ads, there needs to be a distinction between ordinary user accounts and advertiser accounts. Advertiser accounts can customize ad delivery scales, content, etc; while ordinary users can only browse some free content and ads, etc.
Logto is a cloud-based identity solution, and there is also an open-source software (OSS) solution with the same kernel as cloud services for users with special needs to carry out customization. Logto's service is built on a multi-tenant system, where each Logto user creates their own account and can manage multiple tenants within the account. Other various identity cloud services also have similar architectures, with each different cloud service having its own definition of "tenant", so the tenant model we discuss in this article is limited to Logto's scenario, and for other vendors there may be other corresponding concepts.
Notably, in Logto's multi-tenant model, data between tenants (all information of end users) is isolated, so Logto users can manage end user account data according to their business needs within one Logto account. Many other identity cloud services can only support each account having one tenant, which makes users who need to manage multiple tenants at the same time frequently switch accounts, resulting in a poor experience.
After all that, how should you choose an account model suitable for your app? Here we look at three cases.
Case 1: App directly provides service to end users
The identity model in this kind of apps is pretty simple. Let's use a music streaming app for example — other than the admin (Logto’s user “foo”, which is tenant owner in this case, inherently have admin access), there are only end users.
In this scenario, end users can be divided into three types:
- Free plan user: Can only play free music
- Paid plan user: Can play free music and can create their own playlists
- Premium user: On top of playing free music and creating playlists, can also play HiFi musics
In the above application scenario, we only need three types of roles (free, paid, premium), each assigned with different permissions. So after the end user logs in, Logto can decide whether to provide certain specific services (e.g. access to HiFi musics) to him based on the role he has. At this point, we only need a single tenant to meet the requirements.
Case 2: eCommerce platform app
A platform that connects third-party service providers and end users, which is also a very common 2C business model nowadays. There are two user groups to consider - using an e-commerce app as an example, they are merchants (service providers) and buyers (end users).
There are two ways to build the identity model here:
- Put the buyers and merchants user groups under the same tenant.
- Put the buyers and merchants into two different tenants respectively.
To make the example easier to understand, we assume buyers can place orders or view product descriptions; merchants can change product prices, change product descriptions, and view product inventory. Merchants view product descriptions to help them find issues and update product information in a timely manner.
For identity model 1, there is only one app. All users who register become buyers. If someone needs to sell things, they can add their own products for sale, so such end users will obtain merchant permissions in addition to buyer permissions to manage their own products.
For identity model 2, since each tenant has its own unique identity information and its own separate authorization gateway, each tenant needs to have its own separate app. In the example case, there would be a buyer app and a merchant app. Buyer accounts cannot become merchants, and merchant accounts also cannot become buyers. If merchants want to check their own product descriptions from a buyer's perspective like in model 1, they need to reimplement the same functionality in the merchant app, or register a buyer app account to view it. This adds a lot of complexity, but the advantage is that buyer and merchant identities are completely isolated.
If merchants have many different products to manage, using identity model 2 and developing a more specialized merchant app should be a better choice. Model 1 is more suitable for platforms like eBay, where merchants don't have many products and also don't need overly complex product management functionality.
Case 3: Apps made by IT consulting corp
Suppose there is an IT technical consulting company whose clients do not have the ability to develop IT systems themselves, so they need to seek technical services from this company.
Assuming the company has two clients, one being an internal book management system for a bookstore, and the other client is a reservation system for a hotel.
From the bookstore owner's perspective, I obviously do not want the hotel guests to be able to randomly log in to my book management system, as that would be very unsafe. Therefore, from the aspect of protecting the privacy, a separate tenant must be set up for each client, utilizing the tenant information isolation mechanism, to ensure that data of customers is invisible to other customers.
As we mentioned before, even if you have the need to create multiple tenants, Logto can help you manage multiple tenants within one account, which is more convenient and secure compared to some other services that require you to create and manage multiple accounts yourself.
Through the examples shown above, you must have figured out when you definitely need to create multiple tenants, in what scenarios you can have either a single tenant or multiple tenants, and according to your own business needs, choose the identity model solution that suits you best.
The Logto team aims to ensure that the question of "whether multiple tenants should be created" is not a blocker for any business. If you're uncertain whether your business scenario can be achieved with a single tenant, please join the Logto community for consultation. Your question may also be someone else's question, so share the challenges you've encountered with us to help improve the scalability of Logto's products.
If you are selecting an identity framework for your app, Logto is worth a try. It provides an out-of-the-box solution suitable for various business scenarios from small businesses to large-scale applications!