In this article, I’m going to describe how you can use the various aspects of Auth0 and the Auth0 Organizations feature to help deliver IAM functionality typically associated with B2B use cases. And I'll be doing this using a real-world B2B SaaS application that I'm currently developing. Let's get started 😁
What Is a B2B SaaS Application?
Let's start by defining what constitutes a B2B SaaS application. B2B SaaS applications - or SaaS applications as they’re otherwise known - are typically created by a business vendor that sells their product to other business customers for use by internal users (i.e., employees, contractors, etc.) Often referred to as subscribers, these business customers might leverage multiple SaaS applications as part of their corporate IT infrastructure.
Many SaaS applications are designed as such from the start. Others evolve from B2C applications where SaaS is seen as a logical way to create additional revenue streams. However, a SaaS application comes to life, having the flexibility for expansion into alternative markets, if the opportunity presents itself, is an advantageous one: markets such as B2B2B - where a B2B subscriber themselves ends up creating a B2B service that incorporates the vendor application - or B2B2C, where the B2B subscriber ends up creating a direct-to-consumer B2C application (again incorporating vendor technology) are not uncommon. In fact, the SaaS application vendor themselves may have already identified that B2B2B and B2B2C are also opportunities for them in their own right. And they may also end up identifying a B2C market for an application that started life as B2B SaaS.
Tenancy
B2B SaaS applications typically differ from B2C applications - i.e., applications developed for direct-to-consumer use - in several different ways. Firstly, they usually employ a tenant model: that is to say, an instance of the application is typically deployed for each subscriber. Each instance is isolated in terms of data but may share resources such as compute, memory, storage, networking, etc.
Such isolation implies a mandatory need for Authentication and Authorization, as without it, there’s no security, and isolation becomes impossible: without proper Auth, any user could access the data from any tenant and perform any operation - addition, update, deletion, etc. With each subscriber itself a business, there’s often the need to leverage the existing identity provider they employ. This facilitates easy use of existing Identity and Access Management (a.k.a. IAM), such as user profile management and the likes of SSO, MFA, etc. If an existing identity provider (typically referred to as an IdP) such as Okta Workforce or Microsoft Active Directory is being used, then a subscriber to a SaaS application would likely want to configure Auth against these.
In certain cases - i.e., for small business subscribers or subscribers that perhaps employ external staff such as contractors or the like - there could also be a need for the application to provide its own Identity and Access Management. This supports the capability of allowing access without having to set up those users in a subscriber's own IdP - particularly if they don’t currently leverage one.
Administration
Administration for a SaaS application also differs and typically falls into two distinct categories: Vendor Administration and Subscriber Administration.
Vendor Administration can be thought of as the classic administration model where, as the builder of the SaaS application, one or more folks can be assigned to administer overall aspects across all subscriptions. Often referred to as the Super Admin, this would typically include systemwide administration of aspects specific to the application - as well as overall Identity and Access Management. Included here are such things as managing default MFA enrollment policies, User Management, etc., and the assignment of an initial Administrator at the subscriber level for a provisioned Tenant. Whilst much of this is often automated, a Vendor Administrator is also there to take over if something does go wrong.
Subscriber Administration provides something similar but at the subscription level. Often referred to as Delegated Administration, one (or more) administrators are assigned per subscription to manage the various aspects of whatever the application provides, as well as IAM within their subscribed tenant. Administrators at this level won’t typically be able to provision new Tenants - though that’s not necessarily true for B2B2B business models - but they will typically be able to manage the likes of users and user-related identity (such as managing their own tenant MFA policies, etc). A Subscriber Administrator will often be able to provision additional Tenant Administrators at the subscription level, too.
Access Control
Not everyone who could potentially be a SaaS subscription user actually should be a SaaS subscription user! For example, I might not want everyone in my workforce, say, to be able to make travel bookings at the corporate level. So, at a high level, having a way to control who has access - irrespective of what access they then have - is an important aspect. Of course, users will need to Authenticate in order to establish a context for this level of authorization, but once successful, they’ll be allowed to pass.
Once past the first level of authorization - as in getting “through the door”, so to speak - a finer granularity of access would typically be considered the norm. For instance, subscribers will often want to assign additional administrators who can look after certain aspects of their tenant and potentially do so under certain conditions…like the hour of day or office location, etc. And they will likely want individual user access to be controlled, too, typically based on a member’s role or responsibility.
Branding
The look and feel of any application is important; from a Brand perspective, having consumers both aware that they are using a Brand-specific service - and confident in doing so - is valuable. Branded assets also help to build and reinforce brand awareness: a significant aspect of any B2C application, it becomes even more crucial in B2B SaaS applications where there are multiple brands concerned. Depending on what the application does, a SaaS subscriber would likely want to brand numerous aspects - which would, at the very least, include branding the specifics of the application sign-up and login process.
Scalability
Depending on the use case, a SaaS application may need to scale far beyond what any B2C application would. And, given the audience it serves, it will likely need high availability too. Take the Okta platforms, for example; both the Workforce and Customer Identity cloud scale to manage millions of logins per day across literally hundreds of thousands of user communities. Using technology that can scale horizontally as well as vertically - i.e. where additional stacks can be deployed across service providers, as well as more powerful resources within the same stack - is often a requirement. And, in such cases, scalability and resilience will typically extend to any third-party services - such as IAM - that are incorporated too.
Building a B2B SaaS Application Using Auth0
Auth0 is arguably the market-leading solution when it comes to Customer Identity. With an impressive array of features, Auth0 typically takes care of all the numerous aspects associated with the Identity and Access Management commonly seen in both B2C and B2B SaaS application scenarios. One particular feature has been specifically designed to address the challenges associated with B2B use cases - and if you’re building a SaaS application, it will undoubtedly make your life a whole lot easier. That feature is known as Organizations, and it builds on the pedigree of IAM functionality already in the Auth0 platform.
As an Architect, Consultant, and Engineer, I have more than 30 years of experience designing and developing secure and robust software solutions. When not helping teams with the complexities of Customer Identity, you can typically find me working behind the scenes, acting in, or directing a show at my local theatre. In the world of theatre, there are numerous Production Companies that create shows staged live at a theatrical venue (e.g. a theatre, town hall, studio space, etc.). Aside from the performance aspect, theatrical production is largely an exercise that includes a whole host of project management - typically incorporating the likes of Planning, Resourcing, Scheduling, Time Management, Marketing, etc. As a hobbyist, I’m building a commercial-grade SaaS application - TheatricalPA - that incorporates elements of B2C, B2B, and B2B2C application design to provide an automated solution tailored to these specific project management requirements, and in doing so, I’m integrating with Auth0 and the Auth0 Organizations feature for all my IAM requirements.
Registration
The first use case scenario I need to tackle is Registration - i.e. the process where someone becomes a subscriber of a B2B application. In terms of the subscription model you choose, 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 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.
In TheatricalPA, registration takes one of two forms: individual subscriber registration - a la B2C style - and registration as a subscriber on behalf of a Production Company; as in the typical B2B model. As an individual subscriber, I can register with TheatricalPA to provide information about myself - e.g. my experience in acting, say, or working backstage; what shows I like to get involved with, etc. And I can also see the theatre production companies in my area and what they are currently up to.
While registering as an individual subscriber is relatively straightforward - especially using the Auth0 Universal Login feature - registering on behalf of a production company (i.e., a business organization involved in the production of theatrical shows) is somewhat more complex. B2B registration is typically synonymous with (application) tenant provisioning and so is arguably more vulnerable from an attack surface perspective: if you provide automated tenant provisioning as part of registration, which is quite often the norm, then you could quickly find that fake registrations are forcing resources to be consumed unnecessarily within your application infrastructure - artificially increasing your costs, or causing denial-of-service.
There are numerous ways to approach this, but in TheatricalPA, I’ve opted to leverage the Invitation workflow within the Auth0 Organizations feature to provide a fluid user experience that will also mitigate against common attack scenarios. Using the Auth0 Management API, I can ask Auth0 to handle all of the work associated with creating and managing an email invitation workflow and hook up my application tenant creation as part of this, too. I can even brand the emails Auth0 generates to my own specific requirements.
As the Auth0 Management API is also rate-limited, I can leverage this to help protect my own infrastructure during the registration process. For example, if someone with malicious intent is trying to perform large-scale fake registrations, then the number and frequency of these will be limited automatically by Auth0, and Auth0 can also provide me with data that could be used to potentially identify such attacks. Pretty cool, and less things for me to worry about! 😎
Administration
The second use case scenario deals with Administration. Unlike a B2C application - which typically has only one administration context - in a B2B SaaS application, administration typically comes in two forms: the aforementioned Vendor Administration and Subscriber Administration.
Vendor Administration
In TheatricalPA, vendor administration is achieved by using the out-of-the-box administrative UX provided by WordPress. TheatricalPA is a full-stack application - which also includes mobile device access - implemented using classic HTML, CSS, JavaScript, React and React Native at the front end, and PHP at the backend. In building TheatricalPA, I also chose to leverage WordPress - specifically WordPress Multisite, which is itself built using PHP - as technology stack scaffolding to do a large portion of the heavy lifting.
I’ve also leveraged the Auth0 Plugin for WordPress, as well as integrating directly with the Auth0 Management API via my own custom-built WordPress Plugin. In fact, all of the core aspects of TheatricalPA have been developed as a combination of a custom WordPress Plugin and a custom WordPress Theme. Doing this allows me to perform a host of Auth0 operations automatically, particularly where they resonate with existing out-of-box WordPress metaphors.
Whilst WordPress scales horizontally as well as vertically - I can even mix and match platforms as my hosting requirements grow - I picked AWS as the infrastructure provider of choice. Aside from providing a whole host of Auth0-related services, AWS provides an easy-to-use administration dashboard, object storage via S3, and email facilities like SES, together with AWS standard templates (provided, in part, by Bitnami) that make it easy to deploy the likes of Lightsail, MariaDB, etc, which serve as the core WordPress Multisite infrastructure in TheatricalPA.
I've made a number of choices regarding the technology and the scaffolding I'll be using to implement TheatricalPA. My choices, however, won’t necessarily be yours! Thankfully, workflows involving Auth0 are not stack-specific; they can be implemented equally as well with something like Next.JS, for example, or any other tech stack combination. Auth0 really does allow you to build secure identity and access management using any technology, and you can visit our SDK documentation for further details.
Subscriber Administration
As previously discussed, in a multi-tenant model, each tenant will typically share infrastructure - such as compute, memory, network, storage, etc. However, to prevent unauthorized access, the data for each tenant is isolated via the protection afforded via the likes of Authentication and Authorization. So whilst I want to let administrators at the subscription level configure their own individual tenant settings - e.g., Branding, SSO, the use of authentication factors like MFA, etc. - I can’t just let them have carte-blance access to the likes of my Auth0 Dashboard or my entire WordPress Multisite installation. I can’t let one subscriber affect another by the configuration choices they make.
Further, identity isn’t always subscriber-specific; I will likely carry my identity with me from company to company, so no one particular organization will typically lay claim to the sum of the identity information belonging to me. I wouldn’t want the subscription-level administrator for one Production Company, say, to be able to modify - or even delete - my identity information in TheatricalPA that I also use when collaborating with another.
So for Subscriber Administration in TheatricalPA, I leverage the isolation provided by the out-of-box user interface for WordPress Multisite - with some additional refinements to remove functionality that would otherwise be confusing for a subscriber-level admin. As part of this, I once again leverage the Auth0 Management API to seamlessly integrate Auth0 Organization functionality where it resonates with the various WordPress metaphors. For example, as a newly subscribed administrator, one of the first things I’d typically want to do is brand my product experience - making changes from the defaults TheatricalPA provides.
Membership
Lastly, I’m going to cover Membership. Membership is essentially an access control mechanism that is typically prevalent in B2B SaaS applications; in Auth0 Organizations, members typically represent those for whom access is authorized. At least at a high level. Of course, users will need to Authenticate in order to establish a context for authorization, but once successful, if they’re on the member's list, then they’re typically allowed in!
What a member can do once they’re allowed in is a different matter. To determine exactly what actions a user can do at the application level In TheatricalPA, I leverage the Role-Based Access Control (RBAC) in Auth0 - where one or more Roles are typically associated with each member of an Auth0 Organization; the role associated with the first registering user typically being that of the (Subscriber) Administrator. Whilst Auth0 Organizations supports the Auth0 RBAC functionality out of the box, there’s no reason I couldn’t also use Auth0 Fine-Grained Authorization (FGA) as an additional an more refined authorization mechanism.
With Auth0 Organizations there are a number of ways of getting on the member list. One way is by using an automatic approach: that’s to say, when a valid login attempt is made via a specific SSO Identity Provider, the user is automatically added. For instance, let's say I’m subscribed to TheatricalPA as a Production Company that’s using something like Okta Workforce or Microsoft Azure as my corporate Identity Provider. In this scenario, my employees log in via my corporate IdP (Identity Provider) and, by virtue, will be automatically enrolled as members of the Auth0 Organization once they have successfully authenticated and authorized.
Another way of getting members onto the list is by invitation. I’ve already mentioned invitation workflow as part of the registration process in TheatricalPA, and I’m also using invitation workflow as part of the application-level functionality that TheatricalPA provides as well. Membership invitations can be used in a wide variety of scenarios, but for B2B use cases will likely occur where a user is not specifically a direct employee of the subscriber - that is to say, they don’t typically log in via the subscriber's corporate IdP or the like.
One of the things that happens early in the development of any theatrical production is assembling the team that will be part of the show. This will include not only the actors but also the design folks, backstage folks, and technical folks, as well. Bringing together the team is typically the job of the Director with the help of either the Producer and/or the Production Assistant; there are many functions associated with a stage production that fit well with the Role Based Access Control model supported by the RBAC functionality in Auth0. Creating the Production in TheatricalPA will typically be the job of the Subscriber Admin, following which they will likely appoint the Producer and/or Director.
Where a Producer or Director is already a member of an organization in TheatricalPA - either by virtue of automatic membership or because they were previously invited to be part of some prior production - then appointment is simply a matter of course. Following this, their designated role is assigned. However, for new members, invite workflow provides the perfect mechanism for co-opting them onto the team to fulfil a particular role. Once invites have been accepted, each of the invited Producer and/or Director roles will then subsequently have the authority to invite additional members to the production team - again either as a matter of course or by subsequent invitation.
Where to Go Next
If you’ve enjoyed reading this article and you want to know more, then check out the recently released Auth0 Next.js SaaStart. SaaStart by Auth0 provides a template from which you can build functionality to manage members, as well as do things like provision SSO - using either OIDC or SAML via automatic membership - and much more. Also, don't forget to sign up for our Auth0 Zero Index Newsletter for all those tips, tricks and helpful hints, whether you're integrating a B2C or a B2B SaaS application with Auth0!
