An identity provider (IdP) verifies who a user is before granting access. Learn how IdPs work, the protocols they use, and how a weak one breaks your IAM.
An identity provider (IdP) is a service that creates, stores, and verifies digital identities, answering the question "who is this person?" before granting access to applications. When you click "Sign in with Google" on a third-party site, Google is acting as your identity provider: it checks your credentials, confirms you are you, and tells the app, without the app ever seeing your password.
Without a robust IdP at the center of your IAM strategy, authentication fragments across systems, security policy goes inconsistent, and attackers find the gaps between applications. This guide covers how identity providers work, the protocols they use, the failure patterns that show up when the IdP is weak or missing, and what to look for when choosing one. For the customer-facing side of this, our overview of customer identity and access management is a useful companion.
An identity provider is a service that creates, stores, and verifies digital identities, and it answers one question: who is this person? Once the IdP confirms someone's identity, it passes that confirmation to other applications so users reach them without logging in again. You have already used one even if you never learned the term, because "Sign in with Google" is Google acting as the IdP: it checks your credentials, confirms you are you, and tells the app, without the app ever seeing your password.
Every IdP handles three core jobs:
Identity and Access Management is the discipline of controlling who can access what, and at the center of any IAM program sits the identity provider as the single source of truth for identity. Without that central authority, authentication fragments: each app manages its own user database, passwords multiply, and IT loses visibility into who can reach what. The security gaps appear in the spaces between systems.
A strong central IdP changes the dynamic. It centralizes authentication decisions, enforces consistent policy, and gives security teams one place to monitor and control access. When something goes wrong, there is one system to investigate instead of dozens, which is the difference between a one-hour incident and a one-week one. Building on Ory Kratos for that central authentication authority keeps the source of truth in infrastructure you control.
The flow between an IdP and an application follows a predictable pattern, and understanding the sequence clarifies why the IdP sits at the center. Here is what happens when someone tries to reach a protected resource:
Notice what the service provider never does: it never handles the user's actual credentials. It trusts the IdP's signed assertion instead. That separation is the whole point. Applications do not store passwords, and users do not create new accounts everywhere they go.
When organizations lack a mature identity provider, or lean on fragmented ones, the same failure patterns recur. Security teams meet these in real environments, not just risk assessments.
Without centralized identity, accounts scatter across applications. The same person ends up with three usernames, inconsistent permissions, and orphaned accounts in systems they stopped using months ago. Shadow identity, the unmanaged accounts outside IT's visibility, grows every time an employee signs up for a SaaS tool with a personal email or a contractor creates an account nobody tracks. Each one is an entry point security cannot monitor.
When authentication is not centralized, enforcing strong policy gets hard: some apps require MFA while others accept weak passwords, and attackers hunt the weakest link. Credential stuffing shows the problem clearly, replaying stolen pairs from one breach against other services, and it works because users reuse passwords. A centralized IdP with passwordless authentication and adaptive MFA reduces this by removing passwords or adding verification when a login looks suspicious. The full set of techniques is worth knowing, and our guide to credential-based attacks covers them.
Authentication answers "who are you?" while authorization answers "what can you do?" Without IdP integration, permissions drift: users accumulate access as they change roles, and nobody revokes the old entitlements. This is privilege creep, and it is how a developer who moved to marketing two years ago still holds production database access. When a breach hits, attackers inherit whatever excess the compromised account collected. Enforcing least privilege through fine-grained authorization is what keeps that surface from growing.
Proprietary IdPs trap organizations with custom integrations, non-standard protocols, and data that does not export cleanly. What looked like a quick implementation becomes a multi-year migration when requirements change. Open-source and modular architectures avoid the trap, since standard protocols and portable data keep an IAM platform migration a strategic choice rather than a technical impossibility.
Build on a Standards-Based Identity Foundation
IdPs vary by deployment model, audience, and use case. The right choice depends on who your users are and how much control you need over the infrastructure.
| Type | Description | Common Use Cases |
|---|---|---|
| Social IdPs | Consumer platforms like Google, Apple, Facebook | Consumer apps prioritizing frictionless onboarding |
| Enterprise IdPs | Microsoft Entra ID, Okta, Ping Identity | Workforce SSO and directory services |
| Cloud/SaaS IdPs | Auth0, Amazon Cognito, Ory Network | Managed identity for web and mobile apps |
| Self-Hosted/Open Source | Keycloak, Ory Kratos, Ory Hydra | Maximum flexibility and data ownership |
Social IdPs let users authenticate with existing Google, Apple, or Facebook accounts. For consumer apps where reducing signup friction matters more than owning the identity infrastructure, social login often makes sense: users skip another password, and conversion typically improves.
Enterprise IdPs like Microsoft Entra ID and Okta focus on the workforce: employee SSO, directory sync with HR systems, and integration with internal tools. Governance features like access reviews and compliance reporting come standard because enterprises face requirements consumer apps do not.
Managed services like Ory Network, Auth0 and Amazon Cognito offer convenience: no infrastructure to run, automatic updates, built-in scale. The tradeoff is less control over customization and data residency. For teams that want to move fast without running servers, SaaS IdPs cut operational burden, at least until customization needs outgrow them.
For teams that need infrastructure control, data sovereignty, or deep customization, self-hosted options give maximum flexibility. Keycloak and Ory's modular components (Ory Kratos for authentication, Ory Hydra for OAuth 2.0 and OIDC) let you own the identity stack completely. No vendor controls the roadmap, and data never leaves infrastructure you control.
IdPs talk to applications through standardized protocols, and knowing which does what helps when you evaluate compatibility and plan integrations. Four matter most.
Security Assertion Markup Language is an XML-based protocol for exchanging authentication assertions between an IdP and an SP. It dates to the early 2000s and remains widely deployed in enterprise environments. It works well, though its XML verbosity makes it less pleasant to implement than newer options, as our walkthrough of SAML SSO basics lays out.
OpenID Connect is an authentication layer built on OAuth 2.0. It issues ID tokens (JSON Web Tokens) carrying user identity claims and has become the preferred choice for consumer apps and developer-friendly integrations because it is simpler than SAML and uses JSON rather than XML.
OAuth 2.0 is an authorization framework, not an authentication protocol, and that distinction trips up many teams. It delegates access to resources without sharing credentials, answering "what can this app access?" rather than "who is this user?" You will usually see OAuth 2.0 and OIDC together, with OAuth handling authorization and OIDC handling authentication, a pairing our guide to OAuth 2.0 and OpenID Connect use cases unpacks.
System for Cross-domain Identity Management automates user provisioning and deprovisioning: when someone joins or leaves, SCIM synchronizes that change across connected applications. Without it, IT creates and deletes accounts by hand in every system, which is slow, error-prone, and leaves orphaned accounts behind. Wiring up SCIM directory sync closes that gap automatically.
A mature IdP enables three capabilities modern security depends on, and each builds on the IdP's role as the central authority for identity.
An identity-aware proxy like Ory Oathkeeper can enforce Zero Trust policy at the network edge, validating tokens and applying authorization rules before requests reach backend applications, which extends the IdP's decisions to every hop rather than just the login.
Different identity contexts demand different IdP capabilities, and the same organization often uses multiple IdPs, or a single modular set of components, to cover them.
CIAM focuses on consumer-facing authentication: passwordless login, social sign-in, progressive profiling, and consent. The priority is friction-free experience at scale, where a system might handle millions of authentications a day at sub-second latency. Our primer on what CIAM is goes deeper.
B2B scenarios involve federating with partner organizations, self-service onboarding, and mapping roles across organizational boundaries. Partners expect to use their own IdP while your application trusts their assertions through federation, which is the core of B2B identity.
Employee identity emphasizes SSO across internal tools, directory sync with HR, and instant provisioning and deprovisioning as people join and leave. The goal of workforce identity is reducing friction for employees while keeping tight control over access.
As AI agents and automated systems call APIs, identity extends beyond humans. Machine identity means authenticating non-human actors, scoping their permissions tightly, and auditing their actions. Traditional IdPs were not built for this, which is why AI agent identity is becoming its own design surface as organizations deploy agents that act autonomously.
Ory's 2026 community survey found 69.5% of developers already have agentic AI use cases, a category that did not exist in the 2025 survey.
When you evaluate IdPs, a few criteria separate options that scale from ones that create problems later:
Ory provides modular, open-source identity components that scale from proof of concept to production at very large scale. Kratos handles authentication, Hydra handles OAuth 2.0 and OIDC, Keto handles authorization, and Oathkeeper acts as a Zero Trust proxy, each deployable independently or together.
Whether you prefer self-hosted open source, an enterprise license for on-premises deployment, or the fully managed Ory Network, you keep control over your identity infrastructure and data. The IdP stays yours, which is the point that most of the failure patterns above come back to.
Cofertility replaced Auth0 with Ory as its identity provider, ran a silent migration that imported existing password hashes without forcing a single reset, and paired it with a signup redesign that produced a statistically significant 15% lift in account creation.
Fearing 'migration fatigue,' we couldn't risk a platform-wide password reset that would trigger user churn. Ory eliminated this threat. Their robust documentation on secure hash imports and side-by-side migrations allowed for a completely silent transition. We didn't just solve our fluctuating traffic pricing; we upgraded our entire security posture without our users ever feeling the shift."
— Jeremiah Atwood, Head of Engineering, Cofertility (View the case study)
Run Your Identity Provider With Ory Kratos
An identity provider authenticates users and issues identity assertions. A service provider is the application that relies on those assertions to grant access. The SP trusts the IdP and never verifies credentials directly.
No. An identity provider is the system that performs authentication. Single sign-on is a capability the IdP enables, allowing one login to grant access across multiple applications.
Yes. Many organizations federate multiple IdPs: a social IdP for customers, an enterprise IdP for employees, and sometimes a partner IdP for B2B. The application routes users to the right provider based on context.
An identity provider handles authentication and identity verification. An IAM offering is broader: it may include the IdP plus authorization, user-lifecycle management, governance, and compliance.
Common IdPs include Google, Microsoft Entra ID, Okta, Auth0, Keycloak, and Ory Kratos. Each serves different deployment models and use cases, from consumer social login to enterprise workforce management to self-hosted open source.
A robust identity provider is not one line item on the IAM checklist. It is the assumption every other control quietly depends on. SSO, MFA, Zero Trust, provisioning, and audit all resolve back to the IdP being trustworthy, current, and central. When the IdP is weak, nothing fails loudly. It fails in the seams: the orphaned account, the inconsistent MFA policy, the permission nobody revoked. Fix the center, and the edges stop leaking.
