What is an identity provider (IdP)? It is the system that authenticates a person and then vouches for that person to applications. The user signs in once, at the IdP. The IdP gives each application a signed statement, called an assertion or a token, and the application never sees the password.
NIST defines it as “the party in a federation transaction that creates an assertion for the subscriber and transmits the assertion to the RP”.
The application that receives the statement is the service provider, or relying party.
This page covers four points:
- What an IdP does. Its three jobs.
- Kinds of IdP. Workforce, directory, customer and social.
- Protocols. The ones an IdP speaks.
- One IdP, many applications. How a single sign-in serves them all.
What an identity provider does
An IdP has three jobs:
- It authenticates. It checks a password, a second factor or a ticket from a directory.
- It issues a signed statement. Under NIST SP 800-63C, an assertion carries the subject, issuer, audience, issue time, expiry, an identifier and a signature. In SAML this is an assertion; in OpenID Connect it is an ID token.
- It holds policy. Policy decides which applications a person may open, whether a second factor is required and which attributes go to which application.
Federation lets one IdP serve separately-administered relying parties, so an organization keeps one set of accounts and one set of sign-in rules.
- Wider concept. See federated identity.
- Redirect sequence. See how SSO works.
Kinds of identity provider
The labels overlap, and one product can belong to several kinds. The table lists the four common groups, with examples taken from each vendor’s own documentation.
| Kind | Who signs in | Example, as the vendor describes it |
|---|---|---|
| Workforce IdP | Employees and contractors | Microsoft Entra ID, described by Microsoft as “a cloud-based identity and access management service” providing authentication and policy enforcement |
| Directory | Staff whose accounts live in a directory | Active Directory or OpenLDAP; Keycloak documents that it can sync users from LDAP and Active Directory servers |
| Customer IdP (CIAM) | Consumers and business customers of an app | Microsoft Entra External ID, which uses an external tenant kept separate from employees |
| Social login | Anyone with an account at a large consumer service | Google, whose OAuth 2.0 APIs conform to the OpenID Connect specification; Okta also lists Facebook and Microsoft as examples |
A directory on its own stores accounts and checks passwords. It becomes an IdP in the federation sense only when a service in front of it issues SAML assertions or OpenID Connect tokens.
For the directory side, see LDAP vs Active Directory and what Kerberos is.
The protocols an IdP speaks
| Protocol | What the IdP is called | What the application receives | Primary source |
|---|---|---|---|
| SAML 2.0 | Identity provider | A signed XML assertion, usually through the browser | OASIS SAML technical overview |
| OpenID Connect | OpenID Provider (OP) | An ID token (a JWT) with claims about the sign-in | OpenID Connect Core 1.0, section 1.2 |
| LDAP | Directory server | A bind: the application sends credentials and the server says yes or no | RFC 4511 calls Bind the “authenticate” operation |
| Kerberos | Key distribution center | A ticket and session key for a named service | RFC 4120 |
The main difference is who sees the password. With an LDAP bind, the application handles it; with SAML, OpenID Connect and Kerberos, the application never receives it.
Compare the first two in SAML vs OIDC, or read what SAML is and what OpenID Connect is.
How one identity provider serves many applications
The person signs in once. Each application, acting as service provider, sends the browser to the IdP and accepts the signed response.
The application trusts that response because trust was configured in advance, in one of three ways:
| Trust is set up by | Protocol | What each side gives the other |
|---|---|---|
| Metadata | SAML | An XML document that lets entities “express and share configuration information” such as endpoints, bindings and keys |
| Certificates | SAML, OpenID Connect | The IdP’s signing key, so the application can verify the signature |
| Redirect URIs | OpenID Connect | The application registers its redirect_uri, which must exactly match a pre-registered value |
NIST describes the manual version of this step: the RP’s administrator shares the RP’s attributes with the IdP’s administrator.
Adding a tenth application therefore means one more registration at the IdP, not a new password database.
Registration most often fails on entity IDs and audience values. Related reading:
- Registration values. See ACS URL, entity ID and audience.
- The two roles. Compared in IdP vs SP.
- Two ways to start. SP-initiated vs IdP-initiated SSO.
- Sign-out. A separate problem, covered in SAML single logout.
The reverse: many identity providers, one trust point
Production deployments are rarely this simple. Two other patterns are common:
-
Many IdPs into one trust point. After a merger, or when partners bring their own sign-in, an application cannot practically trust ten IdPs one by one. An identity broker sits in the middle: applications trust the broker, and the broker trusts each IdP.
Keycloak describes this as being configured to delegate authentication to one or more IdPs. Microsoft’s B2B model works the same way: guests authenticate with their home organization or identity provider and the host checks eligibility.
More in identity broker.
-
A gateway as the service provider. An older application may not support SAML or OpenID Connect. A gateway or web-server agent then takes the service provider role. It performs the redirect, validates the response and passes the identity to the application in a form it already understands, such as headers.
The SSOGEN Gateway and the SSOGEN Web Agent are two ways to do this.
How to choose an identity provider
Each criterion below comes from a cited source. Okta starts with “a detailed assessment of the existing IT landscape and specific needs”.
- Protocols your apps speak. Compare each application’s supported protocols with the IdP’s. Okta points to SAML, OIDC and OAuth compatibility.
- Where your accounts live. If accounts are in Active Directory or LDAP, check how the IdP reads them. Okta names directory alignment as a check.
- Who signs in. Microsoft separates employees from consumers and business customers into different tenant configurations. Decide whether one IdP should serve both.
- Outside organizations. If partners must use their own accounts, the IdP must accept other providers.
- Assurance level. NIST SP 800-63C defines three federation assurance levels, from a signed bearer assertion up to a holder-of-key assertion signed by the IdP and encrypted to the RP.
- Where it runs. Hosted, or on your own servers. See self-hosted identity provider.
For a product view, see single sign-on software.
SSOGEN as an identity provider
SSOGEN is a complete identity provider, and it can also sign people in through other providers. It supports four kinds of sign-in, which can be combined:
-
local username and password
-
a directory (LDAP)
-
SAML
-
OpenID Connect
-
Typical mix. A few local administrators plus one federated provider for everyone else.
-
Directories. A directory is configured under Identity > Directories, not Identity Providers, because it also brings in users and groups.
-
Sign-in restriction. A SAML or OpenID Connect provider can carry up to 8 required claims, such as a tenant id (
tid) or a Google Workspace domain (hd), each with up to 32 allowed values. -
Details. See identity providers and federated login.
Questions people ask
What is an example of an identity provider?
What does 'identity provider' mean?
What are the most common identity providers?
Is identity provider legit?
Where to go next
- SSOGEN’s own roles. SAML IdP, OpenID Connect provider and multiple identity providers.
- Start with. IdP vs SP, then SP-initiated vs IdP-initiated SSO.
- Protocol detail. What is SAML and what is SSO.
Sources, all read 2026-10-12: NIST CSRC glossary, identity provider; NIST SP 800-63C; OASIS SAML 2.0 technical overview; OpenID Connect Core 1.0; RFC 4511; RFC 4120; Microsoft Entra overview; Microsoft Entra External ID; Keycloak server administration guide; Okta, identity providers; Google OpenID Connect. Product names are trademarks of their owners; SSOGEN is not affiliated with them.