An identity provider (IdP) is the trusted system that authenticates a user and issues the tokens or assertions that let other applications trust that user’s identity without handling the credential themselves. When you "sign in with" one account across many sites, an IdP is doing the authenticating and vouching.

The IdP is the hub that makes single sign-on and federation possible. It’s where credentials live, where authentication policy is enforced, and where trust originates for everything downstream.

How an IdP works

The flow follows a consistent pattern, standardized by protocols like OpenID Connect and SAML:

1. A user tries to access an application (the relying party or service provider).
2. The application redirects the user to the IdP.
3. The IdP authenticates the user: password, passkey, MFA, or a risk-based combination.
4. The IdP returns a signed token or assertion confirming the user’s identity (and sometimes attributes).
5. The application validates the token and grants access, never touching the credential itself.

That separation is the whole point: credentials stay in one hardened place instead of being duplicated across dozens of apps, each an independent breach risk.

First-party, social, and enterprise IdPs

Not all IdPs are the same. A social IdP lets customers log in with an existing consumer account. An enterprise IdP authenticates a workforce for internal SSO. A CIAM platform can act as your own first-party IdP for customers, giving you control over the experience, the security policy, and the data, rather than renting trust from a third party.

Why the IdP is strategic ground

For a customer-facing business, consolidating onto one modern IdP does three things at once: it removes identity silos, it creates a single view of each customer, and it establishes one place to enforce passwordless, MFA, and risk-based decisions. You don’t always have to rip out what exists, a capable platform can extend or sit in front of a legacy IdP, modernizing the experience and adding fraud signals without a risky big-bang migration. Because the IdP is the trust anchor, protecting it with phishing-resistant authentication matters more here than almost anywhere else in the stack.

The IdP as a single point of trust, and failure

Centralizing authentication in an IdP is powerful precisely because everything trusts it, which is also its risk. Compromise the IdP and you potentially compromise every application that relies on it. That’s why the security bar for an IdP is exceptionally high: phishing-resistant authentication (passkeys/FIDO2) for the accounts that hold the keys, strong protection of the signing keys that mint tokens, rigorous session management, and monitoring for anomalous issuance. For customer-facing IdPs, pairing authentication with a fraud and risk engine adds another layer: so even a valid-looking login is weighed against device, behavior, and network signals before trust is granted.

Consolidating and modernizing the IdP

Many organizations accumulate several IdPs over time (a legacy directory, an acquired company’s system, a cloud IdP) which recreates the identity silos an IdP is supposed to prevent. Consolidating onto one modern IdP restores a single customer view and one control point for policy. The catch is migration risk: moving millions of users and credentials without disruption. A practical path is to have the new platform sit in front of or extend the legacy IdP, migrating users progressively (often at their next login) rather than in a single risky cutover. This is how businesses modernize authentication (adding passwordless and fraud detection) without betting everything on a big-bang migration.

First-party IdP vs. relying on a third party

A strategic choice sits underneath all of this: do you operate your own first-party identity provider, or lean on third-party providers (social logins, another platform’s IdP) to authenticate your customers? Third-party logins are convenient and lower the barrier to signup, but they cede control (of the experience, the security policy, and the customer data and relationship) to another company, and they leave you dependent on that provider’s decisions and uptime. A first-party IdP, typically your CIAM platform, keeps that control in-house: you own the login experience, enforce your own passwordless and risk-based policies, and hold the direct customer relationship. Many businesses offer social login as an on-ramp while anchoring the account on their own first-party identity, getting the convenience without surrendering the relationship. For regulated financial institutions especially, owning the IdP is usually non-negotiable, because the security posture and data governance can’t be outsourced.

Frequently asked questions

What is an example of an identity provider?

Any system that authenticates users and issues federated tokens: a social login, an enterprise IdP, or a CIAM platform acting as your first-party IdP.

What’s the difference between an IdP and a service provider?

The IdP authenticates the user and issues the token; the service provider (relying party) consumes that token to grant access.

What protocols do IdPs use?

Most commonly OpenID Connect (OIDC), OAuth 2.0, and SAML.

Can I replace my legacy IdP without disruption?

Often yes, a modern platform can front or extend a legacy IdP and migrate users progressively rather than all at once.

Related: Single Sign-On (SSO) · Identity Federation · OpenID Connect (OIDC) · SAML · IDaaS · Legacy IdP Migration