An identity provider answers one question: is this person who they claim to be? It's the most important question in your identity stack, and also the only one it answers. Everything about what that verified person can then do lives in a different layer entirely.
Every time someone logs into a work app with one set of credentials instead of typing a new password for each tool, an identity provider is doing the work behind the scenes. It's one of the most foundational pieces of modern IT infrastructure, and also one of the most commonly conflated with things it isn't. This guide covers what an IdP actually is, how it works, and where its job stops.
What Is an Identity Provider?
An identity provider (IdP) is a system that creates, stores, and verifies digital identities, and confirms those identities to other services when asked.
Think of it as a trusted notary for logins. When someone tries to access an application, that application (called the service provider, or SP) doesn't verify the person itself. It asks the IdP: is this really them? The IdP checks its records, confirms or denies, and the service provider acts on the answer.
A familiar example: signing into a website using your Google account. Google is the IdP. The website is the service provider. Google confirms your identity; the website never sees your Google password, only Google's confirmation that you are who you say you are.
In enterprise settings, the IdP is usually a dedicated platform (Okta, Microsoft Entra ID, Ping Identity, and similar) that an organization deploys specifically to manage employee identities and vouch for them across every connected application.
What an IdP Actually Does
Three core functions:
Authentication. Verifying that a person is who they claim to be, typically through a password, a biometric factor, or increasingly, multi-factor authentication (MFA) combining more than one of these. This is the IdP's central job.
Identity storage and lifecycle. Maintaining the record of who exists in the organization: usernames, attributes like department and role, and the account's status (active, suspended, deleted). When someone joins or leaves, the IdP's record is often the trigger point other systems watch for.
Federation. Confirming identity across multiple, separate services without each one needing its own login system. This is what makes single sign-on possible, and it's worth pausing on the distinction, because it's the most commonly blurred one in this space.
IdP vs SSO: They're Not the Same Thing
The identity provider stores and verifies identity. Single sign-on (SSO) is the experience of using that one verified identity across multiple applications without logging in again for each one.
An SSO service doesn't store identities itself. It's the intermediary: when a user tries to open an app, the SSO layer checks with the IdP, gets confirmation, and passes the user through. Practically, many platforms bundle SSO and IdP functions into one product, which is why the terms get used interchangeably. Architecturally, they're separate: one verifies, the other relays the verification across a login session.
How Authentication Actually Flows
A typical login sequence, step by step:
- Request. A user tries to open an application (the service provider).
- Redirect. The application doesn't have login credentials on file, so it redirects the user to the IdP.
- Verification. The user provides credentials (password, MFA code, biometric) directly to the IdP.
- Assertion. If the credentials check out, the IdP generates a signed assertion, a piece of cryptographic proof that this user is authenticated, and sends it back to the application.
- Access. The application trusts the assertion (because it trusts the IdP) and grants entry, without ever having handled the user's actual password.
This flow is what eliminates password fatigue and reduces the attack surface of credential handling. It's also entirely about one moment: the point of login. Nothing in this sequence touches what the user can do once they're in.
The Protocols Behind IdPs
IdPs rely on standardized protocols to communicate identity information to service providers. The three that matter most:
SAML (Security Assertion Markup Language). An XML-based protocol for exchanging authentication and authorization data between an IdP and a service provider. It's the long-standing enterprise standard, particularly common for SSO into business applications like Salesforce, Workday, or internal tools.
OIDC (OpenID Connect). Built on top of OAuth 2.0, OIDC is the modern, JSON-based standard for verifying identity, widely used for consumer and mobile-friendly logins ("Sign in with Google" is OIDC in action). It's generally lighter-weight than SAML and has become the default for newer applications.
OAuth 2.0. Technically an authorization framework rather than an authentication protocol, OAuth governs how a third-party application can access a resource on a user's behalf (for example, letting a calendar app read your email metadata) without ever seeing the user's password. It's frequently paired with OIDC, which adds the identity-verification layer OAuth alone doesn't provide.
A fourth, older but still common in enterprise environments: LDAP (Lightweight Directory Access Protocol), used to query and maintain directory services like Active Directory, particularly in on-premises or hybrid environments.
Types of Identity Providers
Enterprise IdPs. Platforms like Okta, Microsoft Entra ID, and Ping Identity, deployed by organizations to manage employee and workforce identities across every connected business application.
Social IdPs. Consumer-facing providers like Google, Facebook, or Apple, used to reduce signup friction for external users of a website or app.
Legacy and directory-based IdPs. On-premises systems like Active Directory, still common in organizations with significant legacy infrastructure, often bridged into cloud IdPs through federation.
Government and legal IdPs. Government-issued digital identity systems, more common in parts of Europe, used for verifying identity against official records.
Most enterprise environments run at least two of these simultaneously: an enterprise IdP for the workforce, and social or legacy IdPs bridged in for specific use cases.
What an IdP Doesn't Do
This is the part most explainers skip, and it's the part that matters most once an IdP is actually deployed.
An IdP answers "is this credential valid?" It does not answer:
- What should this verified person be able to access, specifically?
- Should that access still be valid six months from now, after a role change?
- What happens to every account, token, and permission this person holds when they leave?
- Is the access this person currently holds actually justified by their job, or has it accumulated past what they need?
- Can you prove, to an auditor, who has access to what right now, and why?
Those are authorization and governance questions, and they live in a different layer of the identity stack entirely. An IdP that authenticates flawlessly says nothing about whether the person behind a valid, verified login should have the access they're about to use. That's precisely the gap identity governance and administration (IGA) exists to close: not by replacing the IdP, but by governing what happens to access after the IdP says yes.
Where Zluri Fits
Zluri is an identity security platform for autonomous enterprises, built as four products on one platform: Identity Visibility & Intelligence (IVIP), Identity Governance & Administration (IGA) with its four modules (Access Management, Access Requests, Access Reviews, and SoD), Identity Security Posture Management (ISPM), and SaaS Management (SMP). It integrates with the IdP you already run (Okta, Entra ID, and others) rather than replacing it, picking up exactly where authentication leaves off: discovering every identity and application across your environment, automating access as people join, change roles, and leave, running periodic reviews of standing access, and keeping a continuously monitored, audit-ready record of who has access to what.
The IdP remains the front door. Governance is what happens to everyone once they're inside.
Frequently Asked Questions
What is the difference between an identity provider and a service provider?
The identity provider (IdP) verifies who a user is and confirms that identity to other systems. The service provider (SP) is the application or resource the user is trying to access, and it relies on the IdP's confirmation rather than managing login credentials itself. In a typical login flow, the SP redirects the user to the IdP for verification and then trusts the IdP's response.
Is Okta an identity provider or an SSO tool?
Okta functions as both, which is common among enterprise platforms. It stores and verifies user identities (the IdP function) and also provides the single sign-on experience that lets users access multiple applications with one authenticated session (the SSO function). Architecturally the two functions are distinct, but many platforms, Okta included, deliver both from one product.
What protocols do identity providers use?
The most common are SAML (an XML-based protocol widely used for enterprise SSO), OpenID Connect or OIDC (a JSON-based, OAuth-built protocol common in modern and consumer applications), OAuth 2.0 (an authorization framework often paired with OIDC), and LDAP (used to query directory services like Active Directory, particularly in on-premises environments).
Can an identity provider manage what users can access, not just log them in?
Basic authorization, typically through groups and role assignments, is often available in IdP platforms, but it operates at a coarse level: which applications a group can reach, decided at provisioning and rarely revisited. Deeper access governance (what a user can do inside each application, whether access should change as their role does, and whether standing access is still justified) is handled by identity governance and administration (IGA) tools that work alongside the IdP rather than as part of it.
Do I still need an IdP if I have an identity governance platform?
Yes. An IdP and an IGA platform solve different problems and both remain necessary. The IdP authenticates users and enables SSO across applications. The IGA platform governs what happens to access after authentication: provisioning, lifecycle changes, reviews, and revocation. IGA platforms are typically built to integrate with your existing IdP rather than replace it.
.svg)
