An identity provider (IdP) is the system that checks who a user is and then vouches for them to other applications. The user signs in once at the identity provider, and each application that trusts it receives a signed statement (a SAML assertion or an OpenID Connect token) saying who just authenticated, instead of asking for a password of its own. Okta, Microsoft Entra ID, Google Workspace and Keycloak are all identity providers.
If you build software for businesses, you will meet this term from two directions. Your own company probably uses an IdP to sign employees in to internal tools, and your enterprise customers will ask whether your product can sign their employees in through the IdP they already run. Both conversations use the same word for slightly different jobs, so it helps to pin down what the word covers.
How does an identity provider work?
An identity provider holds, or has access to, the user accounts and the credentials that prove them: passwords, one-time codes, passkeys and so on. When someone tries to reach an application, the IdP is the place where they prove who they are, and it is the only system in that sign-in that sees their password.
After a successful sign-in, the IdP produces a signed message for the application. In the SAML protocol that message is an XML assertion, and in OpenID Connect it is an ID token, which is a signed JSON Web Token (JWT). Either way, the application verifies the signature against a key it already trusts and reads the claims inside, such as the user’s email address, name and group memberships. The OpenID Foundation’s OpenID Connect Core 1.0 specification defines the token format and flow for the OIDC case, and the OASIS SAML 2.0 technical overview describes the same ideas for SAML.
Most IdPs also handle a few related jobs: multi-factor authentication, session lifetime, a user directory or a connection to one, and an audit trail of who signed in and when. Those extras are why people talk about an IdP as a platform rather than a login form.
What is the difference between an identity provider and a service provider?
A service provider (SP) is the application that relies on the identity provider’s answer. In OpenID Connect the same role is called the relying party (RP), and the IdP is called the OpenID Provider. The terms describe roles in a single sign-in, not kinds of companies, so one product can be an IdP in one conversation and an SP in the next.
Your SaaS product is a service provider when a customer’s employees sign in through the customer’s Okta tenant. It is an identity provider when your own mobile app and API trust it to sign users in. Many B2B products end up as both at once, which is the pattern described in our deeper post on how Keycloak plays both roles.
An authorization server is a close cousin that confuses people. In OAuth 2.0 the authorization server issues access tokens that say what a client may do, while an identity provider says who the user is. In practice a single product, including Keycloak, usually does both, which is why the two terms get used interchangeably in casual conversation.
Workforce IdP or customer IdP?
Two kinds of identity provider show up in B2B software, and mixing them up is a common source of confusion in sales calls.
A workforce IdP manages a company’s own employees and contractors, and the company uses it to sign people in to the tools it buys. Entra ID, Okta Workforce and Google Workspace sit here. When an enterprise customer says they want SSO with your product, this is the IdP they mean.
A customer IdP (often called customer identity and access management, or CIAM) manages the users of a product the company builds and sells. Those users sign up themselves, may use social login, and number in the thousands or millions. If you build a SaaS product, the system that signs your own customers in is this second kind. Our CIAM page goes into that side in more detail.
A B2B SaaS product therefore often has its own IdP for end users, and that IdP in turn accepts sign-ins from each customer’s workforce IdP. Putting one IdP of your own in front of many customer IdPs means your applications only ever integrate with one issuer, a design we cover in federated SSO versus a single IdP identity hub and federated identity management for B2B SaaS.
What does enterprise SSO ask of an identity provider?
When a customer asks for enterprise SSO, they are asking for federation, not for a shared password. Their employees should be able to sign in to your product with the account their company already controls, using SAML 2.0 or OpenID Connect, so that their IT team can enforce MFA, disable a departing employee in one place and see the sign-ins in their own logs.
For the identity provider on your side, that translates into a short list of capabilities:
- Support for both SAML and OIDC connections, because customers differ on which they run (see SAML vs OIDC).
- A way to configure one connection per customer without a code change on your side.
- Routing, so a user who types
name@customer.comlands at the right customer IdP. - Automatic user provisioning and deprovisioning, usually through SCIM, covered in user provisioning explained.
- Audit logs that a customer’s security team can ask for.
If you want the step-by-step version for connecting one customer, the SSO implementation guide for developers is the practical companion to this post, and OAuth versus SSO clears up the protocol terms.
Where does identity brokering fit in?
An IdP that accepts sign-ins from other IdPs is acting as a broker. The user authenticates at the customer’s IdP, your IdP verifies that result and then issues its own token to your application. Your application never needs to know whether the user came from Okta, Entra ID or a social login, because it only ever sees tokens from your IdP. That is the main reason B2B products put their own identity provider in the middle instead of wiring every customer directly to the application.
Where does Skycloak fit?
Skycloak provides identity management as a service, and managed Keycloak is the engine behind it today. That means you can run your own identity provider for your product, connect each customer’s enterprise IdP to it, and leave patching and upgrades of the underlying Keycloak to us. The identity providers feature page shows how external IdPs are connected, and the single sign-on page covers the SSO side.
Frequently asked questions
What is an example of an identity provider?
Microsoft Entra ID, Okta, Google Workspace, Auth0 and Keycloak are all identity providers. Social logins such as “Sign in with Google” are also identity provider flows, where Google plays the IdP role for the app you are signing in to.
Is an identity provider the same as single sign-on?
No. Single sign-on is the experience of signing in once and reaching several applications. An identity provider is the system that makes that possible by authenticating you and vouching for you to each application. SSO needs an IdP, but an IdP can also serve a single application.
Is an identity provider the same as a directory?
Not exactly. A directory (such as Active Directory or LDAP) stores user accounts and attributes. An identity provider authenticates users and issues assertions or tokens, and it often reads accounts from a directory behind the scenes. Some products combine the two.
Does an identity provider store my passwords?
Usually yes, for accounts it manages itself, normally as salted hashes rather than plain text. When a user signs in through a federated connection, the password stays at the other IdP and your IdP never sees it.
Do I need my own identity provider for a B2B SaaS product?
If customers will ask for SSO with their own corporate IdP, having one identity provider of your own in front of your apps keeps the integration work in one place. If you only need username and password sign-in for a single app, a simpler setup can be enough at first, but it is worth knowing how you would add federation later.
Is an identity provider the same as an authorization server?
They are different roles that often live in one product. The identity provider tells an application who the user is, and the OAuth 2.0 authorization server issues access tokens that say what a client application may do. Keycloak and most commercial platforms provide both.