Summary#
An IdP is the foundation of enterprise identity: it's where identities live and where authentication happens. But authentication is the beginning of the access lifecycle, not the end. Governing what happens after login (who gets what access, who approved it, and whether it should still exist) requires identity governance on top of your IdP. As non-human identities multiply, that governance layer becomes critical.
An identity provider (IdP) is the system that stores and authenticates user identities. When someone logs into an app using Okta, Microsoft Entra ID, or Google Workspace, the IdP is what verifies who they are and issues a token that tells the app "this person checks out."
That's an essential function. It's also a narrow one, and understanding where IdPs end is just as important as understanding what they do. In regulated industries like healthcare (HIPAA) and financial services (GLBA), who your IdP recognizes and what it allows access to has direct compliance implications.
How an IdP works#
An IdP sits between users and the applications they need to access. The basic flow:
- A user tries to access an application
- The application redirects the authentication request to the IdP
- The IdP verifies the user's identity (password, MFA, SSO token)
- The IdP returns an assertion, essentially a signed statement that the user is who they say they are
- The application grants access based on that assertion
Most enterprise IdPs use open standards (SAML, OAuth 2.0, or OpenID Connect) to pass these assertions between systems, which is what makes single sign-on (SSO) possible across different apps and vendors.
Common IdP examples#
- Okta: the most widely adopted standalone IdP in enterprise environments
- Microsoft Entra ID (formerly Azure Active Directory): the default for Microsoft-centric organizations
- Google Workspace: the IdP for Google-native environments
- Ping Identity: common in large enterprises and regulated industries
- JumpCloud: popular with mid-market and device-focused deployments
Most large organizations have more than one. Mergers, acquisitions, and tool sprawl mean the average enterprise has multiple identity stores that don't talk to each other cleanly.
What an IdP doesn't do#
An IdP answers the question: Is this user who they say they are?
It doesn't reliably answer: Should this user have access to this resource? What level of access? For how long? Who approved it? Has anyone reviewed it recently?
Those are authentication vs. authorization questions, and they require a separate layer. This is the gap between identity authentication and identity governance:
| IdP does | IdP doesn't do |
|---|---|
| Verifies identity at login | Governs what access is appropriate |
| Issues authentication tokens | Reviews whether access should be revoked |
| Enables SSO across applications | Enforces least privilege continuously |
| Manages passwords and MFA | Manages provisioning and deprovisioning |
| Stores user attributes | Provides audit trails for access decisions |
Most organizations discover this gap during an audit, when they need to show not just who logged in, but who approved that access, when, and why.
The non-human identity problem#
IdPs were built for human users. The modern enterprise has a different reality: AI agents, service accounts, automation workflows, and machine identities now vastly outnumber human users in most environments, by an estimated 25 to 100 to one.
These non-human identities (NHIs) don't log in with a username and password. They authenticate with API keys, service tokens, or OAuth credentials, and they often accumulate access far beyond what they actually need, with no review cycle to catch it. AI agents are the fastest-growing and least-governed category of NHI.
In the AI agent context, the IdP's role expands: it doesn't just authenticate humans, it also authenticates agents and issues scoped identity tokens that broker agent-to-app access. C1 acts as the enterprise IdP for both: the central policy-evaluating entity for human and agent identities on one graph. See also: non-employee access management and vendor privileged access.
The question isn't whether your IdP handles NHIs. It's whether your identity governance program does.
IdP, IAM, and IGA: what's the difference?#
These terms are often used interchangeably, but they're not the same:
- IdP (Identity Provider): authenticates users and manages identity data
- IAM (Identity and Access Management): broader category covering the full lifecycle of identity: provisioning, authentication, authorization, and deprovisioning
- IGA (Identity Governance and Administration): the governance layer, covering access reviews, role management, policy enforcement, and audit trails
Your IdP is one component of an IAM strategy. IGA is what operationalizes governance on top of it.
How C1 works with your IdP#
C1 doesn't replace your IdP. It extends it. Your IdP handles authentication. C1 handles what comes next.
C1 connects to your IdP (Okta, Entra ID, Google Workspace, and 350+ other systems) and builds a unified identity graph across every downstream application. C1 also operates 3,000+ hosted MCP servers, extending the same governance to AI agents and their tool calls. On top of that, it runs the governance layer your IdP doesn't have: Intelligent Access Reviews that cut review time by 85%, Just-in-Time Access that eliminates standing privileges with automatic revocation, Dynamic Access Controls that enforce least privilege continuously under a Zero Trust model, and AI Access Management that governs non-human identities (AI agents and service accounts) as first-class identities with owners, role assignments, and access reviews.
The result: your IdP stays the source of truth for authentication. C1 becomes the source of truth for what every identity, human or agent, is actually entitled to do.
For regulated environments like HIPAA and GLBA, C1's Compliance & Risk Management connects identity governance to the audit evidence regulators expect. For implementation guidance, see the identity governance best practices guide and IGA success metrics.
