Organization tenancy: the foundation of SSO and B2B data models

Auth & identity

Engineering

November 17, 2022

Author: Stytch Team

Author: Gedney Barclay

Author: Edwin Lim

Welcome back to B2B Auth School. Our mission is to help B2B companies’ uplevel their understanding and implementation of authentication technologies. Our first series of posts is dedicated to Single Sign On (SSO). This article is lesson two in that series.

In our previous lesson, we introduced you to the wide world of B2B auth. We established the big picture: B2B auth’s challenges, its value adds, and its key differences from B2C auth. Most importantly, we explained why SSO is B2B auth’s most requested feature and thus the topic of this series.

If you recall, we defined the term B2B auth as the authentication of members and their organizations. Members, instead of individual users, change the whole paradigm of authentication because they come in groups. This change requires a new way of designing and building auth flows in applications.

But to talk about SSO, we have to start with the foundation and building blocks upon which B2B SaaS technologies are built. Specifically, we need to talk about organization tenancy – or org tenancy for short. In this post we’ll go over:

Defining org tenancy
The features of org tenancy
Building org tenancy and authentication
How org tenancy unlocks SSO

Is org tenancy the same as multi-tenancy?

Multi-tenancy is the architecture characterized by multiple parties sharing the same resources. The tenants in multi-tenancy can be a wide variety of entities: customers, groups, applications, databases, containers, microservices, or workers. Nearly all SaaS applications implement multi-tenancy in some shape or form.

Org tenancy is a type of multi-tenancy. The tenants are organizations stored in a shared data model as top level entities. Org tenancy focuses and zooms in on the B2B aspect of representing complex organizations like companies as individual customers.

Org tenancy and its elements

Org tenancy is the software architecture that governs multiple organizations within a single application. In other words, org tenancy is the design system that lets organizations coexist together within an application. It helps separate and coordinate resources. Like tenants or residents of a building, each organization uses the application without having to worry about its neighbors because org tenancy provides the walls, hallways, doors, and locks to achieve orderly separation. You may have noticed: the word “organization” is always brought up and emphasized.

By name and design, org tenancy considers organizations as the primary unit of business data; the organization is a first-class entity. In an org tenancy model, the application will always scope an end user’s data and functions to their organization. In more practical B2B terms, we can say: the organization is the customer. Let’s break down the org tenancy model into its elements:

An organization is a grouping or collection of members, resources, settings, and other attributes that can be changed and updated. An organization could have thousands of members or just a few. In B2B auth, an organization (i.e. your customer) is typically a company.
A member is an end user with membership in an organization. Memberships resemble user profiles with attributes like email, username, phone number, role, title, etc. In B2B auth, a member is typically an employee of a company. It is a sub-entity of an organization.
The relationship between members and their organizations is fundamental to the org tenancy model. It dictates the logic and boundaries of the system. For example, like separate apartments, one organization should not be able to access the data of another organization. The application’s structure and features determine how complex or simple these rules and relationships will be.

B2B customers think, speak, and operate in terms of organizations. Org tenancy architecture equips B2B SaaS applications to codify that ideology into the data structure itself.

Two side by side diagrams showing the difference between an app that has users and an app that has org tenancy, in which users are grouped by organization

Features of org tenancy

If you’re a B2B company, you’re dealing with organizations all the time. Your customers are other companies – which are complex organizations by definition. So if you want more than one customer, you need an org tenancy model that will enable your customers to…

Represent the whole enterprise: The entire company should be treated as a single customer. Imagine how impractical it would be if you have to bill every single employee of a company separately for using your application. By grouping everyone into an organization, there’s one invoice for one customer. Remember, the organization is a first-class data entity. In org tenancy, we think primarily at the organizational level.
Manage memberships: A large company could have tens of thousands of employees. To take it further, they might also have a fleet of contractors and consultants that multiply the scale of their workforce. To avoid a huge operational headache, organizations need to be able to control access. An application with org tenancy needs to expose strong tools and definitions for granting and revoking memberships.
Customize and configure settings: A company should have their own preferred settings when using a B2B SaaS application. These settings need to be defined at the organizational level, so all their members will inherit and adhere to them. For example, many companies require that members are only able to invite end users with a specific email domain (@myfakecompany.com) to join the organization.
Structure teams and roles: Companies are composed of several departments (IT, engineering, product, analysts, sales, support, etc.) and several types of members (admins, editors, readers, etc.). Every organization will have a unique team structure and set of roles that compose its internal business-specific operations, and need to be stored somewhere in the application’s data model. This leads to more advanced topics like role-based access control (RBAC) which we’ll cover in future posts.

These requirements are considered table stakes by most B2B customers. If a B2B company doesn’t offer org tenancy, the customer has to deal with the fallout; the customer will need to use their own internal systems and tools to create ad-hoc solutions that can group together all of their employees’ user accounts – essentially replicating org tenancy logic on their end. A B2B company not supporting org tenancy puts a huge onus on customers they won’t be interested in taking on. It's a must-have when companies are purchasing B2B SaaS applications.

Want multi-tenant auth without the headaches? Switch to Stytch.

Building org tenancy and authentication

Now that we understand org tenancy’s importance, let’s talk about the build process. By itself, org tenancy architecture is a lot to construct. When adding authentication on top of that, the challenges start to stack. Here are the key considerations when building org tenancy:

Security and isolation

One of the worst possible things that could happen to a B2B company is data leaking between customers. To prevent this, you need really strong controls to guarantee that the data is scoped to the individual tenant. In SaaS applications, shared resources like databases, microservices, and memory need to be thoroughly tested and vetted for isolation. This is arguably org tenancy’s greatest responsibility and requirement. It’s a matter of security.

Data modeling and design

Unfortunately, there is no exact recipe to define the data model for org tenancy. Every B2B SaaS application must define their own schema to support its features and auth flows. The data model can change drastically depending on what use cases the application supports. When defining the data entities and their relationships, consider these questions: Can end users be members of multiple organizations? Are membership records tied to user records? What structure does the metadata need to be stored in? Can organizations have sub-organizations? And so on.

Org discovery

When an end user logs in to your B2B SaaS application, how do you know which organization they’re authenticating to? It’s a problem of discovery: how to find and identify the right organization based on a login. There are multiple strategies that sit on a spectrum of user friendliness. For a more seamless experience, a B2B SaaS application could attempt to automatically discover the organization from an end user’s membership attributes like email or username. On the other hand, they could require the end user to specify the organization before they can even attempt to log in (this is more thorough, but puts a bigger burden on the end user).

Auth settings

Authentication has many different features and behaviors. Each company may require their own unique combination of these properties for their auth flows. To support that variety, you’ll need to build controls that enable organizations to customize or configure their auth settings. You’ll then need to scope those auth settings to either the organization or member level. The common and fundamental authentication features you should consider supporting are:

Just-in-Time (JIT) provisioning: the immediate creation and hydration of user accounts upon a successful login.
Allowed domains: an approved list of domains that end users must have in order to be a member.
Auth methods: an approved list of authentication methods (Email Magic Links, Passwords, OTP, etc.) that members can use for login.
Invites: the ability to allow members to invite non-members to join the organization.
MFA: the enforcement of multi-factor authentication for login.

The foundation of SSO

The biggest benefit to building org tenancy is that it lays the foundation for SSO. But how? Well, they are inherently linked; SSO is also directly tied to the concept of an organization as a first-class entity. In fact, its authentication scheme relies on the org tenancy data model (organizations, members, and their relationships) to function.

A gif showing how login via a company or organization might work for a B2B application

Org tenancy is a prerequisite because it unlocks the ability for:

Companies to securely manage their whole organization through a single interface.
Employees to have their accounts conveniently linked together.
SSO auth flows to have a single point of access for the organization.

To build SSO, the standard B2B auth experience for your customers, you first need org tenancy to coordinate organizations, members, and their relationships to all work together in concert within your application. For our next lesson, we’ll cover SSO! See you then.