Intro

If you're setting up single sign-on (SSO), there's a good chance you're running into confusing terminology for the first time. That's totally normal. People make this stuff vastly more confusing than it needs to be.

Here, I'll focus on two terms you may have run into:

1. Identity provider (IDP)
2. Service provider (SP)

I'll do my best to explain their different roles -- and help you figure out which way is up.

Let's start, though, by backing up. What exactly is single sign-on?

What is single sign-on (SSO)?

Authentication

Practically all software applications need to authenticate users. That is, they need to know each user's identity. That's because users should only have the ability to view or edit some data.

For example, you probably don't want your summer intern Kevin modifying your CEO's salary in the payroll software your company uses. The payroll software needs to know he's Kevin and therefore shouldn't be editing people's salaries.

Software just don't work properly if it doesn't authenticate users.

Passwords

Conventionally, software applications expect users to authenticate using secret passwords. The mere fact that you can type your password is considered proof of your identity. This is actually a pretty solid way to handle authentication -- except for the fact that people don't really behave.

Companies that worry about security really try to cut down on passwords. It's better for each employee to have one strong password than many weak ones, the reasoning goes. For this reason -- among several others -- companies really try to use single sign-on for everything.

Single sign-on (SSO)

Single sign-on (SSO) is really complicated in some ways, but it's really quite simple in others. Let's dispense with the details and look at SSO in a really general way. Here's what will happen:

• Gloria in sales wants to chat with a customer using Zoom
• Gloria logs into her company's Okta and clicks the Zoom tile in her dashboard
• Gloria's now logged into Zoom

Not so bad, right?

Of course, there are a few important variations of this general flow, but the core idea is the same. Gloria logged into Zoom without using a password; instead, she logged into Zoom using Okta, a separate software application. That's single sign-on: Gloria can identically use Okta to access a variety of other applications, such as Slack or Dropbox or Workday.

SAML as SSO

Single sign-on (SSO) isn't a specific technology. As it turns out, there are several different technologies that can power SSO. However, nearly everyone uses a specific technology called SAML to handle SSO. It actually doesn't matter much for the purposes of this guide, but for the avoidance of doubt, I will hereafter be talking solely about SAML single sign-on.

---

Entities in SSO

Let's go back to the example I gave earlier, of Gloria using Okta to access Zoom. We might observe that there are three entities here:

1. Gloria
2. Okta
3. Zoom

In this case, we'll say that Gloria is the user (unsurprisingly). Okta here is the identity provider (IDP). Zoom here is the service provider (SP).

Let's go over each of their roles.

The identity provider (IDP) in SSO

In the example where Gloria uses Okta to access Zoom, we consider Okta the identity provider (IDP).

I often like to say that IDPs are like glorified databases. Their first core function is simply to store data for a company; IDPs maintain a list of a company's employees and the software applications they can access.

Their secondary function is just to authenticate (i.e., verify the passwords of) the company's employees and relay successful logins over to applications like Zoom.

That's pretty much it.

Common identity providers (IDPs) include the following products:

• Okta
• Entra
• Active Directory Federated Services
• OneLogin
• Ping Identity
• SailPoint
• Jumpcloud
• Authentik

There are a bunch of others as well. They all kind of do the same stuff. They keep track of users and pass on users' authentication contex† to other software applications

The service provider (SP) in SSO

In the example where Gloria uses Okta to access Zoom, we consider Zoom the service provider (SP).

The SP can be pretty much any software. It doesn't really matter what it is. It could be Zoom, Slack, Salesforce, Netsuite... basically any application someone uses at work. Within the narrow context of SSO, all SPs behave exactly the same way.

SPs in single sign-on basically have one job: they need to establish sessions for users when they receive valid authentication claims from an identity provider. The communication a service provider receives from an identity provider simply substitutes for the authentication factors the service provider would normally use (e.g., a password).

---

Am I an identity provider (IDP) or a service provider (SP)?

If handling single sign-on isn't one of the three main things your product does for its customers, you probably aren't an identity provider.

Identity providers like Okta and Entra are software applications managed by corporate IT teams. IDPs always do a few core things: within a company, they keep track of who employees are; they manage a list of software applications that a company uses; and they ferry over employees' authentication context into software applications. If your company's software does all of these things and you consider products like Okta, Entra, and Sailpoint to be your competitors, then you might be an IDP.

If you are integrating with or otherwise communicating with your customers' Okta or Entra (etc.) instances to handle single sign-on, you are a service provider (SP).