All about auth
November 22, 2022
Welcome back to B2B Auth School. Our mission is to help B2B companies’ uplevel their auth game. Our first series of posts is dedicated to single sign on (SSO). This article is lesson three in that series.
Lesson one | Introducing B2B Auth School
Lesson two | Organization tenancy: the foundation of SSO and B2B data models
Lesson three | What is single sign on, and how does it work?
In the previous lesson we went over org tenancy, and why it’s a must-have for any B2B SaaS company. We went over the basic characteristics of org tenancy infrastructure, and key considerations for devs building it for their app. But for the purposes of this series, the most important part of org tenancy is how it enables single sign on.
In this blog post, we’ll go over:
Let’s get cookin’!
Generally, SSO refers to the ability for a user to use a single identity to authenticate and gain access to multiple apps and services. For B2B specifically, we define SSO as the ability for members of an organization to use one identity to authenticate and gain access to multiple apps and services. Members authenticate once and are able to access all of the applications and services they need to use. they’re authenticated everywhere they need to be within their organization.
While there are many different kinds of single sign on like OAuth, WS-Fed, OIDC, or SAML, the key components in SSO are pretty much always the same:
In addition to these four main components, B2B SSO also crucially involves the members of the customer organization.
If we bring all these different components together, their basic relationship to each other in a single sign on transaction looks something like this:
At the highest level, single sign on is simply a communication sequence between the five main stakeholders described above. Depending on which kind of SSO solution you use, you may hear these communications referred to as tokens, assertions, or claims, but the essential function of these is all the same: they securely convey user information between the service provider and the identity provider to securely let customers’ members in. We’ll get into the nitty gritty of these communications in the next blog post, but for now you can generally think of them as a series of browser redirects.
To make this more concrete, let’s imagine the following scenario:
Nine Lives (ie., the customer) is a feline-focused fashion company that delivers clothes to cats all over the world. Jo, their fulfillment manager ( ie., the member) wants to log into Nine Lives’ shipping API Ships Ahoy (ie., the service provider) to make sure a big outgoing shipment is on track.
From Jo’s perspective, this was an easy and straightforward experience: go to the service they want to use, and the SP and IdP work out the rest between themselves. All Jo needs to do is enter their login credentials once, and they’re taken where they need to go.
What Jo doesn’t see is the work being done by both the SP and IdP behind the scenes to make this exchange work. That work includes:
Luckily, Ships Ahoy uses an auth provider to handle all of this work for them. Working with this auth provider, the full work that goes behind an single sign on experience looks something like this:
While Ships Ahoy could do all of this work themselves, they’d prefer that their engineers spend that time working on the tricky, novel problems that are key to Ships Ahoy’s business instead of becoming experts in the intricacies of various SSO protocols.
When a member wants to log into an app or service paid for by their organization, they actually have two choices for how to go about it: they can either go directly to the service provider like Jo did (SP-initiated single sign on) or they can go to the identity provider (IdP-initiated single sign on). This only slightly alters the auth flow for the end user, and still relies on the auth services as a critical relay component in coordinating the auth handshakes between service and identity providers.
If we return to our Nine Lives example, we can think of the user flow as follows:
While the diagram below skips the auth services’ involvement, their role is still functionally very similar to SP-initiated single sign on, in which they’re verifying the assertions and claims about Jo’s identity and role between the SP and the IdP.
Though these sequences appear similar at first glance, IdP-initiated carries a few major implications on the backend for service providers – whether they’ve built their auth services in-house or contract with an auth provider like Stytch:
There are dozens of advantages SSO offers B2B companies, but almost all of them fall into four broader benefits to your customer:
If we think back to our last article on org tenancy, we can see how SSO and org tenancy compliment each other in the B2B SaaS ecosystem. Whereas org tenancy allows for multiple orgs, groups, members within a single B2B SaaS product, SSO allows for members to access multiple applications, services, and resources with a single identity and set of authentication credentials. Both features help B2B customers centralize control of customizable access for organizational members.
The value of that control and customization is indispensable for you to grow your B2B SaaS company. The bigger your prospects are, the more important SSO becomes, because the larger your customers become, the more willing they are to pay for simplicity, orchestration, and efficiency.
Think of it this way: your product is only one of dozens of applications your customers use, and that number only grows higher as the customers get bigger. A recent study found that the average business uses upwards of +88 applications, but for large firms the number can climb as high as 200. Configuring different groups and access permissions for every employee for each of these apps individually can swiftly turn into a headache for IT professionals (not to mention the potential attack vectors if they have unique login credentials for every app).
By offering SSO with your B2B application, you make it clear to your customers you’re committed to reducing their headaches, and keeping their members and assets secure.
In our next post, we’ll get down into the mechanics of the different kinds of SSO, and the tech specs, pros, and cons of each. If you’re hearing your customers ask you about SAML or OIDC, this next post is for you.