👋 Welcome 😁 This is the first in a series that deals with the core topics associated with building a B2B SaaS application. Core B2B SaaS topics typically include things like Subscriber (a.k.a. Delegated) Administration and Invite workflow as well as Multi-Tenancy, and in this article, I'm going to focus on how to architect a multi-tenant solution leveraging the Auth0 platform and the Auth0 Organizations feature in particular. In Part 2, I'm going to focus on implementing a multi-tenant solution and will showcase some of the Auth0 features I've used in the B2B SaaS application that I'm building 😎
Now, if you're completely new to B2B SaaS, I'd highly recommend you first start by checking out my B2B SaaS Application Primer. That article gives you a gentle lead-in to the key concepts involved in building a B2B SaaS application and also introduces Auth0 and the Auth0 Organizations feature 😁 If you're not a complete novice and are building a B2B SaaS application but haven't come across the term Multi-Tenancy, then this article is definitely for you! If you have come across the term Multi-Tenancy but have never heard of Auth0 or the Auth0 Organizations feature, then you too are absolutely in the right place 😎 And even if you have heard of all of those things, this article is still worth a read: you never know, you might just find something that surprises you, and you might just end up learning something new in the process, too 🤗
What is Multi-Tenancy?
If the term "tenancy" conjures up an image of an apartment block full of apartments that folks occupy, then you wouldn't be a million miles away from what the concept relates to in a B2B SaaS context. Tenancy - or, more specifically, the term Multi-Tenancy - is the notion where more than one customer occupies space within your B2B SaaS application. Let me elaborate.
Take the image associated with this article. That image - as in the graphic that forms part of the title of this blog post - shows a cross-section of an apartment building that has multiple apartments. The apartments that we can see are all occupied, with each apartment decorated and furnished in a style unique to each occupant; each apartment is a home where the layout of the contents and the color scheme associated with each largely align with individual tastes and requirements. We can see that each apartment has physical characteristics - i.e. shape, size, etc. - that are defined by the apartment building itself, and we can imagine that each apartment has running water, heating, and electricity that's provided as part of the fabric of the said building.
In comparison, a B2B SaaS application is similar. Like the apartment building in the previous analogy, a B2B SaaS application will typically provide the fabric - i.e. the compute, memory, storage, networking resources, etc. - which each application tenant will share and upon which each will rely. Similarly, per-tenant data and branding are analogous to the individual contents and the color scheme associated with each apartment in the apartment block.
The notion of B2B SaaS tenancy brings more "players" into the game, and with the various B2B2C, B2B2B and B2B2E variations (namely Business-to-Business to Consumer, Business-to-Business to Business, and Business-to-Business to Employee) the use of the terms "customer", "consumer", and "user" can quickly become overused...not to say confusing! 😳 So, when referring to the immediate customer - i.e. the occupant of a tenant/the tenancy holder in a B2B SaaS application scenario - I typically prefer to use the term Subscriber. This is also an apt term, as B2B SaaS often employs a subscription-based model when it comes to the provision and the billing of the services provided. The various B2B variations and the best billing model to use when it comes to a SaaS subscription are beyond the scope of this article, but throughout, I have made a few comments regarding the decisions I've made in TheatricalPA - the B2B SaaS application I'm building - that may be useful 🤗
In contrast, I typically use the term Vendor when referring to the provider of the B2B SaaS application (as in the supervisor/owner of the building in the apartment block analogy). The term Vendor is a good counterpoint to the term Subscriber and also provides useful delineation when it comes to describing the difference between the two administration scenarios. In terms of isolation - a topic I'll discuss in more detail below - whilst each Subscriber is typically kept separate intentionally, a Vendor would likely be someone a Subscriber would want to share access with, given the appropriate consent. Vendor Administration vs Subscriber Administration for B2B SaaS applications is the topic of another blog post I'm working on, so stay tuned for more details! 🤗
So creating a multi-tenant architecture involves several different aspects, each of which you'll almost certainly need to consider when building your B2B SaaS application. Much like in the apartment block analogy, there's typically no "one size fits all" design - apartment blocks come in all shapes and sizes, as do the apartments themselves, and so the "shape" of your application rather depends on the features/functionality that it is intended to provide.
Multi-Tenant Organization
Using the term "organization" is apt as it also refers to the feature in Auth0 that relates to multi-tenancy in an IAM (Identity and Access Management) context - namely the Auth0 Organizations feature - and it builds upon the plethora of existing functionality provided by the Auth0 platform. More on this later 😁
When it comes to B2B SaaS, a Multi-Tenant "organization" typically falls into one of two camps: Sub-domain Organization and Sub-folder Organization. There is a use case for using both sub-domain and sub-folder organizations, but this isn't typically tenant-related, so we won't dwell on it as part of this article. If I were to draw a parallel to our apartment analogy, then one could consider "organization" as the strategy used when it comes to how an apartment is located within the apartment block.
Sub-domain Organization
The sub-domain Organization model is one where a tenant is represented as the sub-domain in the URL associated with a B2B SaaS application. For example, consider auth0.auth0.com. Here, auth0.com is the domain associated with the application - i.e. the Okta Customer Identity Cloud, powered by Auth0; itself a B2B SaaS application - and the sub-domain refers to the subscriber who has a provisioned tenant (more about tenant provisioning later). In this case, the subscriber is auth0: yes, as part of the Okta family, the Auth0 team uses both the Okta Customer Identity Cloud together with the Okta Workforce Identity Cloud internally 🎉
Organization by sub-domain is typically best suited for isolated partitioning when it comes to things like SEO - drawing again on the analogy, think of maybe apartment(s) that form isolated, individual, perhaps gated, communities - and for a number of reasons, it also provides additional safety from an IAM perspective, too. For this reason, the Auth0 Organizations feature supports the use of sub-domain organization as the only configuration option.
Sub-folder Organization
The opposite of Sub-domain Organization is the Sub-folder Organization. In a sub-folder organization model, each tenant is represented as a (sub) folder in the URL associated with a B2B SaaS application. Take github.com/auth0 for instance. Here, github.com is the domain associated with the application - i.e. GitHub; again, being a B2B SaaS application - and the sub-folder refers to the subscriber for whom a tenant has been provisioned: in this case, auth0.
A sub-folder organization model is typically best suited for partitioning when it comes to inclusive search for likes of SEO - for example, and one can perhaps think of it as being similar to, say, an apartment directory in the apartment block analogy, where searching across tenancy is all-inclusive. It's often a model that can be used when creating something like an inter-related blog architecture - e.g. in something like a classic WordPress Multisite scenario - but it isn't as robust from an IAM perspective (and hence why it's currently not supported in the Auth0 Organizations feature). FYI, I'll be talking more about WordPress Multisite later, as it's the technology stack framework/scaffolding that I'm using in the B2B SaaS application (TheatricalPA) that I'm building 😎
Multi-Tenant Isolation
Isolation is all about how the various subscribers in a B2B SaaS application are kept separate from one another. Think about the apartment block analogy: as a tenant in one apartment, I wouldn't want any of the other tenants to come mess with my stuff, layout, and/or decor; I wouldn't want the occupants of any other apartment to just be able to come into mine. However, I might need the building supervisor, say - i.e. the Vendor in a B2B SaaS application scenario - to come into my apartment and perhaps fix things without me being there but with my consent.
Multi-Tenant Data Isolation
When one thinks of isolation in a B2B SaaS application, data isolation is perhaps the first thing that springs to mind: how does one keep the data associated with each subscriber separated and secure. In this context, data represents all that information that is particular to the way a solution works; I'm going to separate data isolation from identity isolation, and I'll cover the latter in more detail a little later 😎 In terms of the former, we can consider that the data for an application would typically be stored in a database - and where doing so has the added benefit of supporting all of the B2B SaaS scaling options as discussed in the Multi-Tenant Performance section below.
Isolated Data Tables
In a table-level isolation scenario, separate database tables are used for each individual subscriber. Table isolation often involves the duplication of more than one database table per database schema - there typically being different tables used in a B2B SaaS application supporting the various aspects of functionality - and is probably the easiest level of isolation to achieve. When it comes to the application logic, accessing different tables within the same schema is arguably easier than switching between multiple database schemas, particularly when referencing common tables that exist as a single instance across all subscription tenants.
Isolated Schemas
Schema isolation often provides a higher level of confidence from a security perspective, so can be employed in applications that need to meet more stringent requirements. However, when it comes to application logic, access across/between different database schemas - as in such cases where access to tables common across all subscription tenants is required - is typically harder. Using multiple database connections can be one solution, though comes at the expense of additional resource usage. So whilst there can be greater resilience to security exposure - due to errors in coding, say - it can make the code inherently more complex due to the way the logic needs to be written.
Multi-Tenant Brand Isolation
Branding can be thought of as being synonymous with the decor of an apartment in our apartment block analogy, and for B2B SaaS subscribers, branding - and by virtue, brand awareness - is important. Branding - or White-Labelling as it's often referred to - not only gives subscription users the confidence that they are using an authorized application, but in B2B2C and B2B2B scenarios, it also gives the end customer/consumer a similar level of confidence, too.
Domain White-Labelling
Domain White-Labelling - typically prevalent in a B2B SaaS Sub-domain Organization context - occurs where a totally unique domain name is used instead of the typical sub-domain organization. For example, in Auth0, one can create a Custom Domain even to the point of bringing one's own domain certificate; for example, I use the custom domain auth.cevolution.co.uk for the Auth0 Tenant I've created and that I integrate into most of the applications I build (B2B SaaS or otherwise).
Multi-Tenant Identity Isolation
When it comes to identity, isolation can typically be categorized in two distinct ways: (i) from an overall user population perspective and (ii) from the perspective of individual subscription Membership. Identity isolation is really where using something like Auth0 can pay dividends: Auth0 can provide for both of these within the context of a single Auth0 Tenant, where all of the platform Identity and Access Management (IAM) capabilities are overarchingly managed through the Auth0 Organizations feature!
Membership
Membership is an important aspect of any B2B SaaS application. Not everyone who could potentially be a SaaS subscription user should be a SaaS subscription user! For example, corporate policy may state that not everyone in the subscribed organization should be able to access the B2B SaaS system that allows corporate travel bookings. Of course, users will need to authenticate to establish a context for authorized use, but once successful, if they're on the membership list, then they’ll typically be allowed in. In the case of Auth0, more information about the Membership capability in Organizations can be found by starting with the Auth0 Docs here.
Moreover, a user could be associated with more than one subscription - something that's particularly true for contractors or third-party suppliers, say. Subsequently, a user will likely want to carry their identity with them from one subscription to another - meaning no one particular subscriber should lay claim to the sum of their identity information.
Overall User Population
Having access to the user population overall - as in all the users that exist across all the subscriptions (tenants) provisioned in a B2B SaaS application - provides numerous opportunities for user convenience as well as additional business value. For example, whilst the Organizations feature in Auth0 provides for per-subscription context from an application tenancy perspective, the Auth0 Tenant centralized user data store provides for consistent user profiling no matter the users' membership(s). For instance, in my B2B SaaS application, TheatricalPA - a subscription-based service for managing theatrical productions - I wouldn’t want the subscription-level Administrator for Dev Rel Studio Productions to be able to modify core aspects or even delete my identity within TheatricalPA...when I also use that information as part of my collaboration with Cevolution Studios.
Additionally, Auth0 Connections - particularly in the case of Auth0 Database Connections - can be independently assigned to each individual Organization to provide discrete isolation when it comes to user credentials and/or the source of user identities.
Multi-Tenant Performance
When it comes to a B2B SaaS application, there is typically only one set of application logic employed across all tenants. At least at the core level - plugin architectures, such as those supported by WordPress, or add-on extension architectures like that supported by Auth0, also offer the ability for nominal logic to be executed on a per-subscriber basis. Irrespective, this means that from a computing perspective, infrastructure often needs to be able to support not only the scale of users you would typically find in a B2C application - but do so at order(s) of magnitude; scale effectively being multiplied by the number of subscribers.
Rate Limiting
Protecting infrastructure becomes important, so the likes of rate limiting - where the rate at which subscription users can hit your servers is controlled - is a crucial aspect of B2B SaaS application design. Even more so where APIs are provided that allow third parties (controlled) access to resources. For an example of this, we can refer to the Auth0 Rate Limiting Policy, which describes how Auth0 leverages rate limiting to protect bot individual tenant infrastructure and platform infrastructure overall. Interestingly, Auth0 rate limiting can be used to help protect infrastructure in certain IAM-centric B2B SaaS application scenarios, and I'll talk more about that later 😁
Whilst rate limiting can offer a certain degree of control, ultimately, a B2B SaaS application will need to scale - either manually or, in many cases, dynamically - as subscribers increase and subscription usage grows. An increase in demand is, after all, what every B2B SaaS application vendor aims to achieve!
Vertical Scaling
Vertical scaling is arguably the easiest to achieve: in this case, scaling to satisfy demand is achieved by increasing compute, networking and/or storage (i.e. memory as well as disk) capacity. With the likes of elastic compute environments provided by third-party vendors such as AWS (see here for more details), vertical scaling can be achieved dynamically, with auto-provisioning occurring automatically based on defined policy or via the use of vendor-specific APIs. Vertical scaling is also the easiest to employ when it comes to tightly integrated database scenarios.
Horizontal Scaling
Vertical scaling, however, has a limit, and it doesn't work particularly well for scenarios requiring load-balancing - either due to geographic location or due to heavy demand from a particular subscriber. For situations where vertical scaling falls short, the option of horizontal scaling is typically where one would go next: horizontal scaling typically involves incorporating additional compute, networking and/or storage (again, memory as well as disk) resources to satisfy demand. I use the term additional here because, in horizontal scaling, one typically talks about using additional physical/virtual machines to which traffic is routed.
Once again, with the likes of elastic compute environments provided by third-party vendors such as AWS, horizontal scaling can be achieved dynamically. Horizontal scaling can also be used in conjunction with vertical scaling and typically works best when database decoupling is employed - i.e. where a separate database service is configured, such as in the case of WordPress Multisite or the like, that, depending on the database service used, can often work better in Data Table Isolation scenarios, too.
Scaling Database Architecture
Whilst we're on the subject of databases, and data decoupling in particular, most modern database engines (particularly SQL database engines) provide the capability to shard - which is where additional database servers/services can be employed, across which the data in the database is distributed. There's a really good article on sharding here that goes into the concept in much more detail than in the time or the space we currently have. In many ways, sharding acts like Horizontal Scaling but at a level specific to the database. Database sharding is largely database engine specific and is beyond the scope of this article - however, there are multiple resources available on the internet that discuss how it can be achieved for the likes of MySQL, MariaDB, MS-SQL Server, etc.
Multi-Tenant Provisioning
Having talked about multi-tenant architecture, let's now look at how what we've discussed can be implemented in practice. Provisioning a tenant in a B2B SaaS application is largely down to the subscriber registration model being used for the type of solution being built. For example, you may decide to employ something like a free-tier subscription to start with - similar to what Auth0 does and what I’ve decided to offer in TheatricalPA, too - or you may choose to only ever register “paying” subscribers. Whichever route you take, you’ll find plenty of resources available on the web that describe the merits of each.
What's Next?
In Part 1 of my article, I've walked through the aspects of architecting Multi-Tenancy in a B2B SaaS Application and also provided some insight into how I'm integrating with Auth0 to help build multi-tenancy in my application, TheatricalPA. In Part 2, I'll be sharing some of the implementation details and providing code examples et al that illustrate how I've integrated with the features in Auth0. In the near future, I'll also be writing more about the other topics I've mentioned in this article, so be sure to watch out for all of these. For now, feel free to comment below and tell us what you think - we always love to hear feedback, positive or otherwise, as it helps us to improve our content! Thank you. Aside from that, here are some additional resources you might like to follow up on that can help you on your journey. Have fun, and I'll catch up with you next time! 🤗
