An identity provider (IdP) is the system that checks who a user is and then vouches for that user to other applications. When someone opens a connected app, the app sends them to the IdP; the IdP signs them in, applying password, multi-factor authentication (MFA) or passwordless methods as policy requires, and returns a signed statement the app trusts. That is what makes single sign-on (SSO) work, and it gives IT one place to control sign-in for many applications.
Not to be confused with Intelligent Document Processing, which is also abbreviated IDP: software that uses AI to read documents and extract their data into business systems.
At a glance
- Authenticates users and issues signed assertions or tokens that applications accept.
- Speaks federation standards, most commonly SAML and OpenID Connect.
- Usually where MFA, conditional access and sign-in logging are enforced for connected apps.
- Often also provisions and removes accounts in connected apps, depending on the app and plan.
- Becomes a critical dependency and a high-value target, so its availability and security matter.
What problem it solves
Without a central identity provider, every application keeps its own usernames and passwords. Users reuse weak passwords, IT resets passwords all day, MFA is set up app by app if at all, and when someone leaves, their access has to be removed in each system separately. Accounts that are missed stay active, sometimes for years.
An IdP pulls authentication into one place. Users sign in once with strong methods; IT sets sign-in policy centrally; and disabling one account blocks new sign-ins to every connected app. Apps with their own local logins are not covered, and sessions already open may continue until they expire unless the app supports session revocation, which is why automated deprovisioning matters too. It also produces a single record of sign-in activity, which is valuable for investigations and audits.
How it works
The directory. The IdP holds or connects to the list of users and groups. That may be its own cloud directory, an on-premises directory synchronized to it, or an HR system feeding both.
Federation. Each application, called the service provider in SAML or the relying party in OpenID Connect, is configured to trust the IdP. They exchange metadata such as URLs and signing certificates.
Sign-in. When a user opens an app, the app redirects the browser to the IdP. The IdP authenticates the user and evaluates policy, for example requiring MFA from unmanaged devices or blocking risky sign-ins. It then sends back a signed SAML assertion or OpenID Connect ID token saying who the user is, often with attributes like email, department or group.
Authorization handoff. The app validates the signed assertion or token, checks that it was issued for this app and is still valid, and starts a session. What the user can do inside the app is decided by the app, often based on attributes the IdP sent.
Provisioning. Many IdPs also create, update and remove accounts in connected apps, frequently using the SCIM standard, so access follows joiners, movers and leavers.
Monitoring. Sign-in logs feed security tools. Because attackers target the IdP directly, some organizations add identity threat detection and response (ITDR).
When it matters for buyers
- When rolling out MFA or passwordless authentication. The IdP is usually where methods and policies are set.
- When buying SaaS. Check whether the app supports SAML or OpenID Connect and automated provisioning on the plan you’re buying; some vendors reserve these for higher tiers.
- When adopting zero trust access or secure service edge. Those services generally rely on the IdP for user identity and group membership.
- During mergers or after inheriting systems. Multiple directories and IdPs are a common source of gaps.
- When planning resilience. If the IdP is unavailable, many apps become inaccessible, so break-glass accounts and provider availability commitments matter.
Questions to ask vendors
- Which protocols do you support (SAML, OpenID Connect, others), and which of our apps have pre-built integrations?
- Do you support automated provisioning and deprovisioning, and for which apps?
- Which MFA and passwordless methods are supported, including phishing-resistant options?
- How are conditional access or risk-based policies configured, and which signals can they use?
- What is your availability commitment, and how do we keep emergency access if your service is down?
- How long are sign-in logs retained, and can they be exported to our security monitoring?
- What is included in each license tier, and which features cost extra?
How it differs from single sign-on (SSO)
Single sign-on is the outcome: a user authenticates once and reaches many applications without signing in again. The identity provider is the system that delivers that outcome, along with the policy, logging and provisioning around it. The broader discipline of managing identities, permissions and access across the business is identity and access management (IAM), of which the IdP is one core component. For identity-aware network and cloud access built on your IdP, see our secure service edge overview.