What is single sign on, and how does it work?

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?
Lesson four | SSO protocols: SAML vs. OIDC
Lesson five | What is OpenID Connect (OIDC)?
Lesson six | What is SAML and how does it work?
Lesson seven | Choosing a B2B auth provider

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:

What single sign on is
How it works
The benefits of single sign on
Why it’s so important for B2B companies

Let’s get cookin’!

What is single sign on?

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.

The five key components of single sign on

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:

Service provider (SP): If you’re a B2B SaaS company, this is you! SPs are software providers (typically one of many) whose customers want single sign on for their members.
Customer: Generally, the customer is the person or entity that would like to use one credential to access multiple apps and services. In the B2C context, this customer is a single person. In B2B, it’s an organization with multiple members.
Identity provider (IdP): This is the app or service that provides, manages, and authenticates the single identity the customer plans to use to access their apps and services. In the B2C context, the identity provider is usually a social identity provider like Google, Apple, or Facebook, and is simply verifying a user’s identity. But in the B2B context, the identity provider both verifies a members identity and which tools and resources that member does or does not have access to. Instead of a social identity, B2B IdPs are usually workforce identity access management providers like Microsoft, Okta, Ping Identity, etc.
Auth provider: Auth provider supply the service provider with the necessary software to allow the customer to authenticate using the credentials managed by the identity provider. Though some B2B service providers choose to build their own auth provider, many decide to purchase a solution from an external SaaS provider that specializes in auth flows like SSO.

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:

How does single sign on work?

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.

Jo goes to Ships Ahoy’s login page, and requests to log in with Nine Lives’ identity provider, Identities-R-Us.
At this request, Ships Ahoy sends Jo to the Identities-R-Us login page.
Jo authenticates with Identities-R-Us using their Nine Lives email, password, and one-time passcode for good measure.
Once authenticated, Identities-R-Us redirects Jo back to Ships Ahoy, where they’re granted access to a dashboard and set of resources specified for their role at the company.

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:

Configuring Nine Lives’ SSO setup, so that their members can access any app or service with one login credential
Initiating the exchange from Ships Ahoy, so a login request from Nine Lives is automatically directed to Identities-R-Us.
Proving to Identities-R-Us the request from Ships Ahoy is valid, so they don’t share user data with a malicious actor.
Verifying the information from Identities-R-Us, so Ships Ahoy can be sure it has not been tampered with.
Parsing the key information regarding Jo’s identity and access so that they can access the right resources within Ships Ahoy’s dashboard.

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.

IdP vs. SP-initiated: what’s the difference?

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 provider 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:

Instead of going to Ships Ahoy, Jo begins by logging into Nine Lives’ identity provider, Identities-R-Us.
Once inside, Jo can view all of the apps and resources Nine Lives has granted them access to, including Ships Ahoy.
Jo selects Ships Ahoy within their Identities-R-Us dashboard. Identities-R-Us then redirects them to Ships Ahoy, and, because they’re already logged in, they are also granted access when they’re redirected.

While the diagram below skips the auth provider’s 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 provider in-house or contract with an auth provider like Stytch:

IdP-initiated single sign on is only possible with one SSO protocol: IdP-initiated SSO is only possible with secure access markup language (SAML). So if your customers are asking for IdP-initiated SSO, you have to make sure your auth provider includes SAML protocol (more on that in our next post!).
IdP-initiated single sign on is more popular and less secure: IdP-initiated SSO is much more vulnerable to attacks. When sent directly from the IdP, messages verifying the member’s identity can be easily intercepted and co-opted by bad actors through things like man-in-the-middle attacks, browser attacks, or leaky code.
IdP-initiated single sign on requires more from SPs to work securely: Because IdP-initiated SSO has so many vulnerabilities, the onus falls to service providers and their auth provider (whether in-house or external) to build in additional precautions and security to protect their customers’ data. By comparison, SP-initiated SSO has fewer security vulnerabilities, and is much easier for both the service provider and the auth provider to manage securely.

What are the benefits of single-sign on?

There are dozens of advantages SSO offers B2B companies, but almost all of them fall into four broader benefits to your customer:

More secure: Over 80% of security breaches are due to compromised credentials, and phishing attacks against corporate systems are on the rise (just ask Uber and Twilio). SSO decreases attack vectors for your B2B customers by reducing the number of passwords their users are responsible for. It also consolidates the auth flow to a single gateway where your customers’ IT teams can guarantee password strength and enforce multi-factor authentication (MFA) flow to protect their members. Though some IdPs have responded to the rise in corporate phishing attacks by investing in phishing-resistant auth, B2B companies can help further secure their customers by working with auth service providers like Stytch who already offer unphishable MFA as part of their solution suite.
Easier to manage: One Forrester study found that nearly 50% of company help desks’ time is spent with password resets. SSO makes life easier for your customers’ IT teams by giving them that time back, and by centralizing the roles, permissions, and authentication credentials of the whole company in one single place. By giving them more control, you make it easy for them to use your product.
Easier to use: Passwords aren’t just a pain for IT admins to regulate – they’re also a pain for individual users to manage. SSO makes it easy on your customers’ employees to access the resources they need, when they need to – with minimal fuss and back and forth. The easier you make it for your product to integrate into your customers’ members’ day-to-day work stream, the better your chances for widespread adoption.
Improves productivity: SSO doesn’t just save your customers’ IT teams time and headaches: it can provide a productivity boost across the entire company. The same Forrester study that looked at help desk time also found that employees spend an average of 11 hours per year entering and resetting passwords (which in a company of 15,000 could cost as much as $5.2 million in wages just for password management). SSO puts that money back in your customers’ pockets.

Why invest in single sign on?

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.

Till then!