In the authentication space, SSO can be an unfortunately vague term. For some applications, it means “Sign in with Google.” For other applications, it means “We allow you to log into our product with your work account, like Okta or Azure AD.”

In this post, we’ll look at the common terminology in this area, with examples for when you would need them.

What is SSO?

Single sign-on (SSO) is when a user uses a single account to access more than one application.

Example without SSO

In order to understand that, let’s look at an example without SSO login first.

Let’s say you are building a product and you want people to be able to sign up and login to your product. You create a signup form, collect emails and passwords, securely store them in your DB, and built out ways for your users to update their information.

The folks who sign up are creating an account directly with you. This account only exists in your DB and it doesn’t give them access to anything other than your product.

Adding SSO to our Example

Now, let’s say we go ahead and implement the most ubiquitous examples of SSO: “Sign in with Google.”

Your users no longer need to provide an email address or password, they just click on the “Sign in with Google” button, consent to Google sharing your users’ login credentials with you, and you can check with Google to make sure the user is who they say they are.

The reason this is a form of SSO is because the user is leveraging their single account with Google to log into your product. Their single Google account gives them access to every product that implements Sign in with Google.

To help distinguish it from other forms of SSO that we’ll look at in a second, this is also sometimes called a social login.

What is the problem Enterprise SSO is solving?

Let’s now look instead to the world of B2B or multi-tenant software. These are products that are typically used by companies instead of just individuals. You can look at products like Slack or Hubspot or Zendesk - basically any product that is meant to be used by a group of people together.

And let’s go back to our example product. We have implemented basic signup/login, but now all our customers are asking if they can invite their coworkers to it. We add a concept of an organization to the product, and if our customers are small, we can likely get away with just an invitation flow:

The first person to sign up from a company will invite the rest.

This will actually work fine until you get some larger customers, at which point they will ask two questions:

• Do I really need to manually invite every employee I have to your product?
• Is there any way to automatically remove employees that have left the company?

The underlying thought behind both of these questions is “As a larger company, we are constantly adding new employees and removing folks that have left. We also just have a lot of products that employees need access to and managing all of that is a security nightmare.”

Wouldn’t it be nice if instead of managing an account for each one of the products they use, this customer could instead just manage one single work account and dictate who has access to it?

What is Enterprise SSO?

Enterprise SSO is a form of single sign-on where your can use your single employer-provided account to gain access to more than one application.

There is one critical difference between Enterprise SSO and Social Logins:

With a social login, you are just given access to the product.

With enterprise SSO, you are given access to your company’s information within the product.

Put differently, the first time a user logs in with a social login, you:

• Ask Google who this user is
• Create an account for them

But, the first time a user logs in with enterprise SSO, you:

• Ask the employer who the user is
• Create an account for them
• Add that account to the appropriate organization/teams within your product

And this actually explains something that’s uniquely challenging about enterprise SSO. You aren’t just adding one “Login with Google” button to your UI and moving on. When your customer wants to set up an enterprise SSO connection to a new product, they actually have to do some work on their end and exchange information with you. In some ways, it’s like you are implementing an SSO connection per-customer, instead of just one global one.

This is also why you’ll find places ask for your email address or company name/ID when on a login page when you select enterprise SSO. They can’t just redirect you to Google - they need to know which enterprise SSO connection to use, because each connection is unique to a specific customer.

How does your employer provide you with an account?

One thing we glossed over was the idea of an employer-provided account. Where does that come from?

The technical term is with something called an identity provider (IDP). If you’ve worked at a small startup, you’ll find that a common identity provider is Google Workspace.

At larger companies, you’ll find solutions like Okta, Azure AD, JumpCloud, OneLogin, etc as IDPs. This is typically managed by some combination of IT and HR.

What is SAML?

The simplest explanation of SAML is that it’s the most common method for implementing Enterprise SSO.

While the implementation details of SAML are tricky, the user experience of SAML actually looks incredibly similar to our “Log in with Google” case from before. The user is redirected to their work account, asked to login, and then redirected back to the product.

Pretty much every identity provider supports SAML, so, in theory, if our product supported SAML, we can set up enterprise SSO with all your customers. Unfortunately, in practice, the SAML spec can be pretty vague and each identity provider uses different terminology, so you’ll likely end up with a lot of customizations per provider you support.

At PropelAuth, we provide step-by-step guides for your users to set up SAML / Enterprise SSO themselves. This allows us to both provide clear steps on exactly what your users should do, and also lets us collect the information we need to set up the connection fully on your behalf.

This also means your users don’t have to guess if the ACS URL is the same as the Reply URL is the same as the Single sign on URL is the same as the Assertion Consumer Service URL.

There’s just one more major feature to look at and it’s SCIM.

What is SCIM?

The primary use case for SCIM (pronounced like skim as in milk) is to sync user data from an identity provider to your product. It’s typically used in addition to SAML and it’s sometimes called automatic provisioning.

When a user signs in with SAML, you’ll get all the latest information. You’ll get their email address, their ID, any extra attributes the customer has chosen to send. But what happens in between logins?

Let’s say they go away and don’t sign in to your product for a month. In that month they get married, their name changes, and their email address changes.

We don’t see any of that. We will continue to see their information from the last time they logged in. The next time they log in via SAML, we’ll see the new name and email address and we can update our information. This is called just-in-time (JIT) provisioning.

If their employer had set up SCIM, in addition to SAML, shortly after the user’s information is changed, the identity provider will actually send us an update which includes all the user’s changes so we can update it immediately.

Now you might be thinking… who cares? The information will be updated the next time they log in, which seems fine. The biggest use case for SCIM is actually not keeping user’s metadata up to date, its deactivating accounts for employees that have left the company.

SCIM can also send updates like… this user shouldn’t be able to log in anymore, so please log them out and deactivate their account. In our experience, this is the most common reason customers ask for SCIM.

Summary

There’s a lot of terminology in the SSO and Enterprise SSO space. As a really quick summary:

• SSO can be used any time a user leverages their single account to use more than one product.
• Enterprise SSO is a specific case where the account is an employer provided account, and the employer is dictating which products the employee has access to.
• SAML is one way to implement Enterprise SSO.
• SCIM is a common addition to SAML which allows employers to automatically de-provision accounts simultaneously from all the products they use.