An identity provider (IdP) is the system that authenticates a user and then vouches for them to other applications with a signed statement, such as a SAML assertion or an OpenID Connect ID token. In single sign-on (SSO), you sign in once at the IdP, and applications that trust it accept that proof instead of asking for their own password.
Key Takeaways
- An IdP authenticates users for applications that trust it.
- Your app redirects you to the IdP, receives its result and validates the proof before creating a session, as in the SAML browser sign-in flow.
- Workforce identity serves employees, while customer identity serves a product’s users, a distinction reflected in Microsoft Entra’s tenant configurations.
If you build software for businesses, you encounter IdPs from both sides. Your employer may use one to sign employees in to work tools, while your customers may ask your product to accept sign-ins from theirs. We will follow that second situation through a sign-in, then explain where your own identity provider fits.
How does an identity provider work?
An IdP authenticates people on behalf of applications that trust it. The application delegates the identity check, then uses the result to decide which account is signing in. You configure that trust before accepting a login, so your app knows which provider’s proof it should accept.
SAML, short for Security Assertion Markup Language, exchanges the result through XML assertions. An assertion can identify the user, describe their authentication and carry attributes such as an email address. Your app reads that information only after validating the response.
OpenID Connect (OIDC) uses an ID token containing claims, meaning statements about the user and authentication event. You will encounter different message formats and configuration fields, but the same basic task: establish who signed in and whether the proof is meant for your application.
Follow an SSO sign-in from the application
Imagine an employee opening your SaaS product and choosing their company’s sign-in option. The following example follows an application-initiated login, using the browser SSO flow for SAML or the authorization code flow for OIDC.
- The user opens your app. Without an application session, the app starts a login request to the configured customer IdP.
- The browser goes to the IdP. The request identifies the application and where the response should return, as shown in the SAML request example and OIDC request parameters.
- The IdP authenticates the user. It may ask for credentials and multi-factor authentication (MFA), meaning an additional authentication factor. If an acceptable IdP session already exists, another prompt may not be necessary.
- The IdP returns a result. In SAML’s Redirect/POST flow, the browser delivers a response containing an assertion. In OIDC’s authorization code flow, the browser returns a code, which the app exchanges for tokens.
- The app validates the proof before signing the user in. It verifies the signature using trusted signing material, checks who issued the proof, whether it was intended for this app, its validity period, and its relationship to the login request. Only then should it establish the user’s application session, following the SAML processing rules or OIDC validation rules.
In the OIDC authorization code flow, that code exchange matters because the browser returns a temporary code rather than the ID token itself. Use a maintained protocol library to handle the exchange and validation checks. For more on implementation, see our SSO implementation guide for developers.
The SAML Redirect/POST browser SSO flow follows the same broad progression, though it returns an assertion instead of using OIDC’s code exchange. The vocabulary changes between protocols, but the roles in this example remain comparable:
| SAML terms for the sign-in | OIDC terms for the sign-in |
|---|---|
| The application is the service provider (SP). | The application is the relying party (RP), also called the client. |
| It sends an authentication request, or AuthnRequest. | It sends an authentication request to the authorization endpoint. |
| The identity provider authenticates the user. | The OpenID Provider authenticates the user. |
| A response carries the assertion to the Assertion Consumer Service (ACS), the app’s receiving endpoint. | A code returns to the redirect URI; the app exchanges it at the token endpoint for tokens, including an ID token. |
| The assertion identifies the subject and may contain attributes. | The ID token identifies the subject and contains claims. |
| The SP validates the response and assertion. | The RP validates the ID token and flow response. |
If you need to choose which protocol your product accepts, see our SAML versus OIDC guide.
What does SSO IdP mean?
An SSO IdP, or SSO identity provider, is the identity provider that authenticates users for a single sign-on setup. SSO describes the experience of reaching connected applications without repeatedly entering credentials, and the IdP is the system those applications trust. For example, you can configure Google Workspace as the IdP for a SAML application, so employees use their managed Google accounts to sign in.
For a custom Google Workspace SAML app, you configure the integration and turn on user access before users can use it. SSO does not mean every application shares a password, or that an authenticated employee automatically has permission to use every application: authentication and authorization are separate processes. Your product still decides what that person can do after sign-in.
The walkthrough above begins at the app. A SAML login can also begin at the IdP’s application launcher, which changes the request context available to the receiving app. For more on that distinction, see IdP-initiated versus SP-initiated SSO.
What is the difference between an identity provider and a service provider?
The identity provider authenticates the user, while the service provider consumes its assertion. In OIDC, the corresponding application role is the relying party. These describe roles within a connection, so a system can consume an upstream identity and issue its own proof downstream. The Keycloak guide describes that intermediary in its identity brokering chapter. Its brokering overview shows Keycloak validating the external response and issuing its own token.
Your SaaS application is the SP when it accepts a customer’s SAML login directly. When a broker sits between them, your application trusts the broker and the broker trusts the customer’s IdP. For more on these roles, see our guide to how Keycloak can be both an SP and an IdP.
An OAuth authorization server has a related role: it issues access tokens for access to protected resources. That is a different job from supplying the ID token your application uses to identify a user. For more on those roles, see our explanation of OAuth versus SSO.
Workforce IdP or customer IdP?
A workforce IdP serves an organization’s employees and contractors. A customer IdP serves people using the products an organization builds. Customer identity and access management is often shortened to CIAM, and our CIAM page covers that side in more detail. In Microsoft Entra, this distinction appears as workforce tenants for employees and external tenants for customers.
Imagine a B2B customer whose employee uses your SaaS product: that person is an employee to the customer and a product user to you. If the customer’s IT team manages the work account, plan how your product will connect the authenticated identity to the correct customer organization and application permissions. Separating those responsibilities makes an enterprise SSO request easier to scope.
Examples of identity providers
This table shows the role each named offering commonly serves. It is a guide to the product boundaries, not a claim that a vendor supports only that use case.
| Provider | Workforce or customer identity? | Example in a B2B sign-in |
|---|---|---|
| Microsoft Entra ID | Workforce; Microsoft also provides customer identity through External ID external tenants. | A customer’s employees sign in with their work accounts. |
| Okta Workforce Identity | Workforce. | An employer provides SSO across work applications. |
| Google Workspace | Workforce sign-in for enterprise cloud apps. | Managed Google accounts authenticate to a configured SAML application. |
| Auth0 | Customer identity, with business-to-consumer, business-to-business and employee scenarios documented. | A SaaS product integrates its customer login with Auth0. |
| Keycloak | Can serve workforce or customer applications, depending on your configuration. | Your provider accepts a customer’s upstream login and supplies tokens to your app. |
The features list in its administration guide includes browser SSO and sign-out, identity brokering, social login, and user federation with LDAP or Active Directory.
For further reading on B2B identity, see federated SSO versus a single IdP identity hub and federated identity management for B2B SaaS.
What does enterprise SSO ask of an identity provider?
Enterprise SSO requires a trust relationship with the customer’s IdP and agreement about how to identify users. Before implementing it, ask the customer which protocol they support, what identifies a user, which attributes they will send, and who should have access. In a Google Workspace SAML connection, for example, you configure application endpoints, map attributes and turn access on for the intended users.
Plan sign-in, account creation, access removal and session termination as separate requirements. Test whether disabling an upstream account ends existing downstream sessions, rather than assuming it does. In Keycloak, the guide on managing user sessions notes that signing out all active sessions does not revoke outstanding access tokens. Those tokens must expire naturally unless an applicable revocation mechanism is used. Include departure and session-expiry behavior in your acceptance tests alongside successful sign-in.
If you are evaluating your own provider, consider these requirements, and see our guide to choosing an SSO provider for B2B SaaS.
Where does identity brokering fit in?
Identity brokering lets your IdP accept authentication from another IdP and issue its own result to your applications. In the Keycloak broker flow, the user authenticates at the external provider and returns with an authentication response. After validation, Keycloak can create a local user or link the external identity to an existing account. You configure account linking through the first login flow.
You still need to decide how external identities map to local accounts. For example, determine whether a returning employee should link to an existing product account or create a new one. For further reading, see our explanation of Keycloak shadow accounts and the identity store.
Where does Skycloak fit?
Our documentation overview introduces the service. Our identity providers documentation covers connecting external providers for your application’s end users, including “enterprise systems like Active Directory and SAML providers”, which is how you accept your first customer’s enterprise IdP at your own provider. The identity providers feature and single sign-on feature pages summarize what that includes.
To connect an organization’s identity provider over OIDC or SAML, see our enterprise SSO setup guide.
For your first customer connection, agree on the protocol and account mapping, connect their enterprise IdP to your own provider, and test sign-in through your application. Test rejected access and user departure as well, so the integration matches the customer’s expectations beyond a successful login.
Frequently asked questions
Is an identity provider the same as a directory?
A directory can store accounts and attributes, while an IdP authenticates users and supplies proof to applications. A product can combine those functions or connect to an external directory. The Keycloak guide’s LDAP provider section illustrates that arrangement. Its storage-mode documentation describes importing users into the local database, while passwords stay in LDAP and are validated there.
Does an identity provider store my passwords?
An IdP can store passwords for accounts it manages itself. Keycloak’s password policy section and its password-policy documentation source specify hashing before storage or validation, rather than storing cleartext passwords. When the IdP brokers to another provider instead, the password never reaches it: in the Keycloak broker flow, the user authenticates at the external identity provider and comes back to Keycloak with an authentication response. Your application never needs the upstream password in either case.
Does reading a token prove that it is valid?
No. Decoding a token shows its contents, but does not establish trust. Your application must perform the protocol’s validation checks before accepting it. For more on signing keys, see our JWKS explanation. The JWT token analyzer helps inspect token structure during development.
Do I need my own identity provider for a B2B SaaS product?
You can integrate your application directly with a customer’s IdP, or use a broker to centralize customer connections. Consider the broker approach when several applications need the same login and account-mapping behavior. Start by identifying which system owns each account and which issuer each application trusts, then choose the integration around those responsibilities.
To try that setup with managed Keycloak, start a free Skycloak trial, which runs for 21 days with no credit card required, and connect your first customer’s enterprise IdP. Our subscription plans documentation lists what the trial includes.