Previously in B2B Auth School, we went over org tenancy, and why it’s a must-have for any B2B SaaS company.

In this lesson, we’ll look at the main feature driving demand for B2B auth: single sign on.

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 (SSO), 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 this blog post, we’ll go over:

• What is single sign on?
• The benefits of single sign on
• How it works
• Why it’s so important for B2B companies
• Common mistakes to avoid when implementing

What is SSO?

Single sign on (SSO) is the process of allowing end users to securely authenticate to multiple applications based on their authenticated identity on another application.

In other words, SSO allows login to your app by proxy – the user signs in to a different app, that you trust to vouch for the user’s identity. You never store login credentials, but they can still securely login. Magic!

Security benefits of SSO

The main security benefit of leveraging an SSO solution for both you and your end users is that it eliminates the need for a distinct set of user credentials on each application.

For end users, SSO means security with ease. Because single sign on protects access to multiple cloud applications without the need to remember multiple passwords, it helps reduce password fatigue (and subsequent password reuse). Instead, user identities are proven through another application – ideally one where they actually use a unique, strong password and additional security measures like multi-factor authentication.

For you the app developer, it helps mitigate security risks by storing fewer potentially reused user passwords that could be exploited on your application via a credential stuffing attack.

How does single sign on work?

There are several different flavors of SSO solutions, depending on both the protocol chosen and the use case involved – but before we get into the details of the different protocol options, let’s review the basic commonalities of how all single sign on transactions work.

Every SSO process involves two parties:

1. Service Provider (SP): the application the user is trying to access
2. Identity Provider (IdP): the application that manages the user’s identity and is responsible for authenticating them

Prior to being able to enable single sign on, the Service Provider will need to register with the Identity Provider – establishing a way for both parties to securely identify one another, and ensure that the requests aren’t coming from a malicious actor.

Once the registration is complete, a basic Single Sign-On flow involves the following steps:

1. End user opts for SSO

For SSO to happen, the end user needs to be on the SP and indicate in some way that they wish to authenticate via a specific IdP

2. The SP redirects the user’s browser to the IdP

This redirect contains specific authentication request content that tells the Identity Provider what SP you came from, what information to send the SP, and where to redirect you back to upon success.

3. Enter user credentials

If the user is not already in an authenticated state, they will be prompted to provide their login credentials for the IdP.

4. The IdP redirects the user’s browser back to the SP

Once the user logs in and the IdP has validated the user credentials, the IdP will redirect the user back to the SP, typically with an authentication token. This redirect will contain some sort of information that the SP can then use to validate the response from the IdP, according to some set of trusted rules that are pre-configured.

5. Access = granted

Once redirected, the end user is now in an authenticated state on the SP.

The core basics of this flow remain largely the same regardless of the protocol chosen – but depending on protocol there are some differences in data type, format, and authentication mechanisms that allow the parties to securely identify one another and ensure this is a valid request. The primary protocols used in SSO solutions today are OpenID Connect (OIDC) or SAML (Security Assertion Markup Language).

SSO vs. OAuth

The SSO flow described above probably seems pretty familiar to you if you’ve ever done (or implemented) ‘Sign-in with Google.’ And for good reason: it’s a form of single sign-on facilitated via the OAuth/OIDC protocol, and most commonly referred to as ‘OAuth.’

OAuth is a type of SSO, but not all SSO is OAuth

So yes, the OAuth flows you’re familiar with count as single sign-on, and it’s an excellent login option to add to your B2B application. It improves security by eliminating the risk of reused user credentials, and reduces the support burden associated with forgotten passwords and password resets. In particular, email provider OAuth (such as Google or Microsoft) has the added benefit of providing a strong guarantee that the user has real time access to their corporate email account, which offers a stronger signal that the end user is still a part of the organization they are trying to access than password based login.

However, OAuth isn’t what your enterprise customers are talking about when they ask if you offer SSO authentication.

How SSO solutions are different in B2B

Relieving IT admin

Imagine you have 500 employees, who each need access to ~20 different applications to do their jobs. That’s 10k different accounts. When you onboard even five people, that’s 100 new app-specific invites you need to send. Every time an employee leaves, you need to frantically identify all the apps they used, and revoke the user’s access as quickly as possible. As you can see, this is an absolute nightmare from both a security and time perspective.

Instead, enterprise companies use a “workforce Identity Provider” which is a company-specific IdP instance that serves as a centralized source of truth on all employees’ identities and the applications they can access. Their employees will authenticate to these applications via a custom Single Sign-On setup (often referred to as an Enterprise Connection, or SSO Connection) that directs to the company’s specific workforce IdP instance. A successful response from the workforce IdP confirms both the user’s identity, and that they have been granted access to the SP.

This centralized source of truth on employee identity information and access, makes it possible for your customer’s IT Admin to quickly and efficiently make changes to profile information, user access and easily do user access auditing through this workforce IdP. Most Identity Providers also offer ways for IT Admins to group employees based on department or seniority to make application assignment, or Role assignment within those applications, even easier.

Element of Authorization

The main distinction between SSO done through GitHub or Google OAuth and enterprise SSO comes down to whether or not the Identity Provider provides some element of authorization.

Normal Google OAuth will verify my identity – but it doesn’t have any concept of whether it’s the right email to use, or if I should be able to access the SP. On the other hand, if my company sets up an Enterprise SSO Connection via Google Workspace (a workforce IdP), then the SP will redirect to my company’s specific Google Workspace instance where I must prove that I have credentials to access an @stytch.com account. Once I have successfully authenticated, the IdP will verify that I have been granted permission to access that specific application, before deciding whether or not to redirect me back to the SP to successfully complete the SSO flow.

Mistakes to avoid when implementing single sign-on

Before you start digging into the weeds of how to implement a SAML or OIDC SSO solution, there’s a few gotchas that you’ll want to be aware of before starting on solution design.

“Smart” detections of the redirect URL

The first step in an SSO flow is that the SP redirects the end user to the IdP. In OAuth, the redirect URL for the IdP is the same for all users – but in “enterprise SSO” this URL is different for each individual SSO connection, and your application needs a way to determine what redirect URL to use.

One common solution to this problem is to create a mapping between email domain and tenant/organization or SSO Connection, and then have your initial login form just be an email input. If the end user enters an email that is tied to an SSO Connection, you automatically redirect them to the appropriate SSO URL. If the email domain isn’t mapped to an SSO Connection, you show them the standard login options such as OAuth or email and password.

This flow has two issues:

1. Automatic redirect assumes that a given corporate email domain will only ever need to access a single organization or SSO Connection.

This assumption is not correct at scale – as large companies often need to subdivide their employees into different tenants – either within the SP (your app) or the IdP – for a range of reasons: access management, corporate structure, moving IdP providers, etc.

2. Surfacing information about the user’s membership without first authenticating opens up an account enumeration vector.

If you do this discovery based exclusively on the email address, without first requiring authentication, malicious actors can exploit this flow to learn information about your end users and customers

To ensure your SSO implementation is future proof you should make sure to:

1. Design your data model to account for tenants having multiple SSO connections, and email domains (and specific email addresses) to belong to multiple tenants.
2. Offer tenant-specific login pages (e.g. megacorp.your-app.com or your-app.com/megacorp) so that you can identify on page load which tenant the end user is trying to login to and surface all available SSO connections for that specific tenant.

No Backdoor Access

Once a customer has set up an SSO Connection to their workforce IdP, they will want to enforce that all users login via SSO. However, SSO Connections can be brittle, and require maintenance – such as adjusting Attribute Value mapping or rotating the shared secret used to do verification.

If your application makes the assumption that this login method enforcement is all or nothing, it will be impossible for your customer to make necessary updates to the SSO configuration without suddenly allowing all of their employees to authenticate through less secure login methods.

Instead, you should make sure to introduce the concept of a “breakglass” role or permission to bypass the login method requirement, allowing companies to grant to specific users the ability to login through other non-SSO methods if needed.

Not accounting for different IdPs or protocols

Most companies build an SSO solution when they land their first enterprise customer who requires it – and that customer will already have their workforce IdP and their preferred authentication protocol of choice (unfortunately it is almost always SAML).

But the more B2B customers you take on, the more variation you will find in their SSO requirements. SAML is the more common protocol, but OIDC is gaining traction with younger companies every day. And there is a wide range of IdPs to choose from – your best bet is to set yourself up in a way that you’re ready to work with at least the major IdPs.

Trusting the IdP too much

If your application allows a single email to have a membership to multiple organizations (which it should, but that’s another topic) you might assume that a successful authentication via a specific SSO connection is sufficient to log the user into all of the organizations they belong to under the returned email address. After all, your enterprise customers are adamant that SSO login is the most secure option!

Not so fast. Workforce IdPs might offer strong guarantees of the user’s identity within their own system – but there’s no guarantees around whether or not the returned email address was verified. There’s no reason your other customers should trust the identity information coming from the black box that is another company’s IdP, and as such SSO authentication should only ever issue a session for the specific Organization that the SSO Connection is scoped to.

Building it yourself

Sorry, shameless plug – but if you want to avoid all of this, just use Stytch and we take care of the headaches for you. Our B2B auth solution is built to flex with you as you scale and take on customers with more complex enterprise requirements – without requiring extra build time on your part.

If you want to read more about the details of implementing SSO before making your decision, check out our blogs covering the implementation details of SAML and OIDC.