IdP vs SP: What is a Service Provider and an Identity Provider?

Single Sign-On (SSO) allows users to access multiple apps from a single place. It’s extremely vital to large organizations as they add more and more apps to their ecosystem.

At the core of any SSO implementation are two key players: The service provider and the identity provider, with each playing a crucial part in the SSO process.

In this article, we'll break down the differences between a service provider and an identity provider and discuss how they work together to enable SSO.

What is a Service Provider?

A Service Provider (SP) is a website or app that provides services to users. This could be any kind of SaaS app, from a B2B project management tool to a design platform.

If you’re building an app, the SP is you! (Or, more specifically, your app).

As the service provider, you don’t have to authenticate users yourself. Instead, you can rely on a trusted third party — an Identity Provider (IdP) — to confirm a user's identity. All your app needs to do is verify the authentication responses your app gets from the IdP before logging in users.

What is an Identity Provider?

An identity provider (IdP) stores and manages user identities like usernames, emails, passwords, and permissions. In an SSO process, it authenticates users and passes the user’s identity to SPs.

IdPs are the backbone of the SSO process — they centralize user authentication within an organization, which ultimately allows users to access multiple SPs from a single platform.

What are some common Identity Providers?

Below are some of the common IdPs you’ll find potential enterprise customers using:

• Social IdPs like Facebook, Google, and Twitter.
• Microsoft Entra ID (formerly known as Azure AD)
• Okta
• JumpCloud
• LastPass
• ForgeRock
• PingFederate
• Keycloak
• Google Workspace/Cloud Identity

How do Service Providers and Identity Providers work together for SSO?

To facilitate SSO, SPs and IdPs work together by passing authentication requests and user details back and forth. The SP sends the authentication request to the IdP, and the IdP returns a token. This token contains identity data which confirms whether or not the user has been validated, how long the login will remain valid, and essential identity information, like a username and email address.

A single IdP can serve multiple SPs, meaning users can authenticate once with the IdP and gain access to connected apps. That’s SSO in action.

This is possible through SSO protocols like SAML (Security Assertion Markup Language), and OpenID Connect (OIDC) which dictate how user data is formatted and secured during the authentication process. They provide a standardized language that IdPs and SPs can mutually understand.

There are two main SSO flows:

• SP-initiated SSO
• IdP-initiated SSO

SP-initiated SSO: How it works

As the name suggests, SP-initiated SSO starts from the SP’s side. With “Sign In With” type of identity providers like Apple or Google, the SP typically exposes a login button, which, when clicked redirects the user to the IdP for authentication.

More commonly, in enterprise settings, the SP usually has an input box where the user is asked to enter their email address. Upon entering their email, the SP  determines which IdP (if any) the user uses and redirects them to it.

Here’s how it works:

• After a click on the login button, the app generates an authentication request and redirects the user to the IdP.
• The IdP verifies the user’s identity and generates a token, and then redirects the user back to the app.
• The app validates the response (is it from a trusted IdP? Was it tampered with? Does it say the user is authenticated? etc.)
• If valid, the app grants the user access.

SP-initiated SSO is ideal if you want to offer multiple login options to different IdPs.

However, keep in mind that this diversity of IdP choices can be very confusing for users — they might not remember which button they clicked, which account they used to log in, or even whether they created an account to begin with.

IdP-initiated SSO: How it works

Unlike in SP-initiated SSO, IdP-initiated SSO is initiated from the IdP. Once a user logs in to their IdP, they can select the specific app they want to log in from a list of several SPs — to which the IdP redirects them. This could be a corporate login portal or any other system that the organization uses to manage user app access.

Here’s how it works:

• The user first logs into the IdP's portal (or into their corporate device).
• After authentication, the user selects the service (SP) they wish to access from the IdPs dashboard or menu.
• The IdP generates a token that includes the user's identity and possibly other attributes like roles or permissions.
• The IdP sends the user, along with the token, directly to the SP.
• The SP receives the token, validates it, and grants access to the user without further login prompts.

IdP-initiated SSO is mostly used in enterprise environments where employees access a suite of apps through a corporate IdP.

Frequently asked questions

What is the difference between a Service Provider and an Identity Provider?

A Service Provider is an application or service that users want to access, while an Identity Provider authenticates those users and validates their identities. The SP trusts the IdP to securely handle logins.

What is the difference between SP-initiated SSO and IdP-initiated SSO?

In IdP-initiated SSO, the user logs in first to their IdP and then selects the app they want to log in to from a menu while in SP-initiated SSO, the user logs in directly from the app which then redirects them to the IdP.

What protocols do Identity Providers and Service Providers use?

The two most common SSO protocols are SAML and OpenID Connect (OIDC).

Next steps

Adding support for SSO to your app?

Try WorkOS — With a single integration, you can support both SP-initiated and IdP-initiated SSO for any major IdP.

• Get started fast: With SDKs for every popular platform, and Slack-based support, you can implement SSO in minutes rather than weeks.
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard — whether they bring 10 or 10,000 users to your app.

Explore Unified SSO by WorkOS.