I’ve been building authentication and identity platforms for years, always for a different company that needed a strictly B2B Auth story. It was about the 4th time around that I decided it would be the last time, leading me to co-found Wristband. At Wristband, we are developing an auth platform that's focused on solving the specific needs of B2B SaaS applications:

• First-class multi-tenancy
• Out-of-the-box SSO
• Real-time user syncing and provisioning
• Customizability at the tenant and application levels
• Comprehensive role-based access control

Building B2B authentication is undoubtedly a complex task, and its concepts can often feel esoteric.  We understand these challenges, and in this article, our aim is to simplify some of that complexity by presenting a digestible summary of the key components of B2B authentication.  We will also delve into how each component works and why it is necessary for B2B applications.

Key Components of B2B Authentication

Multi-Tenancy is the foundation of B2B authentication

In B2B SaaS, multi-tenancy means running one application instance for multiple customer companies, or “tenants”. The benefit is that by sharing infrastructure resources between customers, businesses can more efficiently and cost-effectively scale their software without deploying a new application instance per customer.  However, this model necessitates stringent data isolation to prevent leaks between tenants.

For B2B software, customers are typically other companies, and users are their employees.  When multi-tenancy is applied to B2B SaaS, each customer company is mapped to a tenant, and company users are scoped to their respective tenants.

Scoping Users to Tenants

To safeguard sensitive data, it’s crucial that users are scoped to their company’s tenant. This scoping ensures that users in different tenants are isolated from each other, preventing user data conflicts between tenants. For instance, having the same user email across tenants doesn’t cause issues thanks to tenant-specific user scopes.

Designing Login For Multi-Tenancy 

The fact that users are scoped to their company's tenant impacts how login flows are designed for B2B SaaS. Instead of a standard login field, B2B SaaS systems require users to log into their specific tenant. This could be initiated by a request for a company identifier (like a company domain) at the beginning of the login process, directing the user to a tenant-specific login page.

Streamlining Tenant Discovery

While this approach is simple to implement, one downside is that it can be challenging for users to remember their company identifiers.  A user-friendly approach to this is allowing users to enter their email, and receive a link that shows all associated companies. Selecting a company directs them to the right login page, bypassing the need for remembering complex identifiers. 

To optimize this tenant discovery flow, if the login identifier entered by the user is unique across all tenants, we can skip the email step and send the user directly to their company's login page. 

Furthermore, if the user knows their tenant login URL upfront, they can enter that URL into their browser and skip the tenant discovery step altogether.

Single Sign-On (SSO)

The convenience of SSO

Another important concept for B2B authentication is SSO. SSO systems let users access multiple applications with one set of credentials, streamlining operations across services without repeated log-ins. In the B2B context, this means using a central identity provider (idP) that manages user identities and authentication requests. This idP is usually managed internally by the customer company, enhancing security and integration with other corporate functions.

Integrating SSO

Support for SSO integrations is essential for B2B SaaS customers.  To understand why, imagine a company using hundreds of B2B SaaS applications internally.  If each internal application does not support SSO, employees must maintain separate login credentials for each application.  This sort of scenario introduces security vulnerabilities and reduces productivity as employees switch between services. 

To enable SSO in a multi-tenant app, tenants must integrate with one or more idPs using standard protocols like SAML or OIDC.  For tenants with idP integrations enabled, their login pages should allow users to select which idP they want to use to authenticate.  After choosing an idP, the application will redirect to the idP’s login flow to complete the authentication process.  Once the user successfully authenticates, the idP will redirect the user back to the application.

User Syncing and Provisioning

Just-In-Time (JIT) Provisioning

In the last section, we discussed how SSO allows company employees to access all their applications with a single login.  However, before an application can use an idP for SSO, the identities managed by the idP need to be provisioned within the application. In the past this was handled by IT admins, but the modern standard for any business is to automate this process. The two most common approaches for syncing users between a company directory and an application are JIT (Just-In-Time) provisioning and SCIM (System for Cross Identity Management).  

JIT provisioning creates user accounts as they log in via SSO, using identity attributes provided by the idP. It's efficient for onboarding but lacks mechanisms for deactivating users when they leave the company

SCIM for Comprehensive Management

The System for Cross-domain Identity Management (SCIM) offers a more robust solution, handling both provisioning and deprovisioning of users. SCIM allows for real-time synchronization of user data across systems via a standardized API, supporting complex user management needs including group memberships.

Compared to JIT provisioning, SCIM is a more complete solution for synchronizing identity information. However, to utilize SCIM, the application and the idP must implement the SCIM protocol, which isn't a trivial requirement. Therefore, support for SCIM might not always be available. In cases where SCIM is unavailable, companies can utilize JIT provisioning as a viable alternative.

Customizing Authentication Flows

Customization Needs

For B2B applications, customer companies need to tailor authentication processes to meet their specific security requirements. This includes setting up custom SSO integrations and configuring multi-factor authentication (MFA) policies.  In addition, it's common for customer companies to want to customize the look and feel of authentication flows to match their company's branding.  Brand alignment is paramount during authentication because it assures users that the application they're logging in to belongs to their company, further instilling confidence and trust in the application.

Self-management of Configurations

Due to the high level of customization each company can have over its authentication flows, it's best to allow each company to self-manage its configurations.  If companies are not allowed to self-manage their configurations, then each time they want to change authentication behavior, they would need to reach out to the B2B SaaS provider's customer support team to make the alterations for them.  While this approach may work for a small number of customers, the number of incoming configuration requests could become unwieldy as the number of customers increases.

Role-Based Access Control (RBAC) Simplified

Role-Based Access Control (RBAC) Overview

Though distinct from authentication, RBAC is a critical component of identity management in B2B applications. It ensures that employees only access information pertinent to their roles. For example, only members of the finance team can access financial records, while HR personnel can view sensitive employee data. In RBAC, roles define a set of permissions linked to job functions. Assigning a role to a user enables them access to specific resources, and the system's authorization rules then confirm these permissions before allowing the operation. This method effectively secures sensitive information and streamlines user management. 

Basic RBAC Model

In simpler use cases, roles can be defined without specific permissions, which means authorization is purely based on these roles. This approach, while straightforward, can complicate matters in more complex scenarios. For instance, without clear permissions, it’s difficult to determine what access a role grants unless the codebase is thoroughly examined. Moreover, adding new roles requires significant code changes to incorporate them into the existing authorization framework.

Scalable RBAC with Permissions

A more scalable method involves linking specific permissions—defined by actions and resources they relate to (like “document:read” or “document:create”)—with roles. This setup not only clarifies role privileges but also simplifies the creation of new roles, as permissions are predefined and do not require code adjustments. This flexibility is crucial in B2B environments where custom roles are frequently needed.

Role Assignment

The final topic to address regarding roles is their assignment process. Roles can be assigned in several ways:

• Admin Provisioning: Directly by admins during user setup
• Self-Registration: Users can self-register and be automatically assigned default roles.
• SSO and JIT/SCIM Provisioning: Roles are assigned based on attributes provided by the identity provider (IdP), like group memberships, during SSO login processes. This automatic synchronization is particularly valuable in multi-application landscapes, ensuring users have appropriate access rights across all platforms. 

Flexible support for assigning user roles is critical for B2B SaaS applications since each customer company might require different user onboarding approaches.

Wrap-up

In contrast to B2C applications, where users authenticate with personal identities, B2B applications require authentication as company employees. Handling employee authentication involves more complex requirements such as stringent user isolation, seamless SSO integration, automated user syncing and granular customization.  Not providing these capabilities can turn away potential customers and hinder a company's growth.   

I’ve learned through experience that comprehensive, reliable authentication solutions are key to both operational security and customer satisfaction in the B2B space. Hopefully you found this post useful, either way I’d love to hear from you directly if you have thoughts on how to make B2B Authentication even more streamlined. You can email me at david@wristband.dev or reach out to me on LinkedIn.