What Is an Identity Provider (IdP)?

An identity provider (IdP) is a service that authenticates a user or other subject and sends a relying application trusted identity information about that authentication, allowing the application to establish a session and make its own access decisions without directly handling the subject's primary credentials.

An enterprise IdP creates a common sign-in authority for many applications. Instead of every application maintaining a separate password and authentication process, applications rely on the IdP's signed statements or tokens. This arrangement supports centralized authentication controls and single sign-on across separately administered services.

An IdP proves an authentication event; it does not automatically grant every requested permission. The application, gateway or other relying party must validate the IdP's response and apply its own authorization policy. An IdP also does not configure or secure the employee's laptop merely because that device participates in sign-in.

The broader discipline of identity and access management covers identity records, credentials, authentication, authorization and lifecycle governance. An IdP is one service within that system. This article places it in the identity trust layer.

Why identity providers matter

Without a shared sign-in authority, each application may hold its own user accounts and passwords. That model multiplies credential stores, produces inconsistent authentication controls and makes access harder to remove when a person changes roles or leaves. It also gives users more credentials to manage.

An IdP concentrates authentication in a controlled service. Applications can accept a defined identity protocol and trust relationship instead of implementing every authentication method themselves. The organization can then apply consistent sign-in requirements while each application retains responsibility for the actions and data it authorizes.

This division supports single sign-on, but IdP and SSO are not synonyms. The IdP is an actor that authenticates and issues identity information. SSO is the user experience in which one authentication can support access to multiple connected applications without repeated credential prompts.

How an identity provider works

A federated sign-in connects a subject, an IdP and a relying party through a configured trust relationship. A common application-initiated flow follows these steps:

1. The user requests an application. A browser or client asks to open a protected resource at the relying party, sometimes called a service provider.
2. The application starts federation. The relying party sends the user to the configured IdP with information identifying the application and the sign-in request.
3. The IdP authenticates the user. It evaluates the available credential, authenticator, session and policy requirements. The method might include a password, passkey, security key or another supported factor.
4. The IdP issues a response. After successful authentication, it creates a signed assertion or token containing a subject identifier, information about the authentication event and approved claims.
5. The application validates the response. The relying party checks the issuer, signature, audience, time limits and request-binding values required by the protocol and local trust configuration.
6. The application authorizes access. It maps the subject to a local account or entitlement and decides what that subject may do. A valid IdP response is an input to this decision, not the complete decision.
7. The parties record evidence. The IdP and application create sign-in and access events for operations, investigation and audit according to their policies.

Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) are commonly used for these exchanges. They represent identity information differently, but both separate the authentication authority from the relying application. Identity federation explains the protocols and trust relationships in more detail.

Core identity provider responsibilities

An IdP commonly performs several related functions, although the exact feature set depends on the provider, deployment model and license.

• Authenticate subjects. The IdP verifies an approved authenticator or recognizes a valid IdP session under current policy.
• Represent identity. It binds the authentication event to a stable subject identifier and selected identity attributes.
• Issue identity claims. It creates a signed assertion or token for a specific relying party and intended use.
• Maintain federation trust. It publishes or exchanges identifiers, endpoints, signing keys and protocol metadata needed to validate messages.
• Apply authentication policy. It can require particular methods, authentication strength or additional verification according to available context.
• Manage sessions. It establishes, limits and ends its own authentication sessions, while connected applications manage their separate application sessions.
• Produce sign-in evidence. It records authentication outcomes and relevant events for support, detection and audit.

Some IdPs also contain directories, application assignments, provisioning services, access-policy engines and identity-governance features. Those capabilities are adjacent to the IdP role rather than part of its minimum definition. A directory stores identity records; an IdP uses identity records to conduct authentication and communicate a result.

An enterprise identity provider example

Fictional manufacturer Alder & Finch uses one enterprise IdP for its human-resources portal, design system and travel application. Priya opens the design system from her company laptop. The application has no password for Priya, so it redirects her browser to the IdP.

The IdP finds an existing session but the design system requires a fresh, stronger authentication for design exports. Priya completes the required authentication. The IdP issues a short-lived response intended for that application, identifying Priya and providing the approved claims.

The design system validates the response, maps Priya to her local account and checks its own project permissions. It allows her to view the assigned design but denies access to an unrelated restricted project. The IdP established who authenticated and how; the application decided which designs Priya could access.

Later, Priya's account is disabled during offboarding. New IdP authentications stop, but administrators must also address active application sessions, local accounts, tokens and assigned access. Centralized authentication improves control, yet it does not make every downstream session disappear automatically.

Enterprise IdP examples

Microsoft Entra ID, Google Cloud Identity and Okta are examples of identity platforms that can perform an enterprise IdP role. They should be evaluated as implementations of the same architectural role, not treated as interchangeable products or ranked within a definition article.

• Microsoft Entra ID can act as the IdP for connected applications, authenticating users and returning identity information through supported sign-in methods. Microsoft's Entra overview describes the user, application and Microsoft Entra ID roles in its SSO flow.
• Google Cloud Identity can serve as a primary IdP for Google services and configured third-party applications, or it can participate in an architecture that uses an external authentication authority. Google's identity architectures distinguish the central IdP from the authoritative source where corporate identities are created and managed.
• Okta can operate as the application-facing IdP and can also connect to upstream enterprise or social IdPs. Okta's IdP documentation shows how its role changes when it brokers authentication from another provider.

This provider section does not define separate Microsoft Entra ID, Google Cloud Identity or Okta topics. It illustrates that one platform may act as an IdP, a relying party, an identity broker or several of these in different trust relationships. Architecture and configuration determine the role in a specific transaction.

Identity provider and UEM responsibilities

An IdP and a unified endpoint management (UEM) system can contribute to the same access decision, but they manage different objects and produce different evidence.

The IdP may consume device-related signals during authentication or access evaluation. Those signals can come from a UEM system, operating-system service or endpoint-security tool. The IdP must preserve their meaning and freshness rather than turning a general compliance label into proof that a device is safe.

Conversely, UEM can assign configuration and report device state without authenticating the employee to every application. Once the responsibilities are separated, organizations can use unified endpoint management to maintain managed-device context while the IdP and relying application handle authentication and resource access.

Benefits of an identity provider

An enterprise IdP can improve consistency and reduce duplicated authentication work when applications integrate with it correctly.

• Fewer primary credential stores: Connected applications do not need to receive or validate the user's main enterprise password.
• Consistent authentication policy: The identity team can apply supported authentication requirements across multiple relying applications.
• Simpler sign-in: A valid IdP session can support SSO when application policy permits it.
• Central sign-in visibility: Authentication events can be reviewed in one identity layer, alongside application-specific access records.
• Faster access changes: Disabling an identity or changing an assignment can affect connected services, subject to session, provisioning and application behavior.
• Protocol-based integration: Standard federation reduces the need for a unique authentication design in every application.

These benefits depend on complete application coverage, reliable identity data and correctly maintained trust configuration. An application that keeps an unmanaged local login can bypass the intended central control.

Identity provider risks and limitations

Centralizing authentication concentrates both operational value and risk. Important failure conditions include:

• Service dependency: An unavailable IdP can interrupt new sign-ins across many applications. Resilience and controlled recovery paths are part of the architecture.
• Broad account compromise: A stolen or abused IdP session may reach multiple connected applications, limited by their authorization and session controls.
• Federation errors: Incorrect audience, redirect, certificate, signing-key or claim configuration can block legitimate access or weaken validation.
• Stale application sessions: Disabling an IdP account does not necessarily end every relying-party session immediately.
• Excessive claims: Sending more identity attributes than an application needs increases privacy and data-handling exposure.
• Weak application authorization: A valid token cannot correct excessive permissions inside the relying application.
• Unmanaged fallback accounts: Local passwords and emergency access paths can undermine central policy if they are not tightly governed and tested.
• Confused trust chains: Identity brokering can obscure which system performed authentication, sourced an attribute or made an access decision.

No IdP can prove that a device is uncompromised, that an authenticated user will act safely or that an application enforces correct authorization. Identity evidence must remain one input within a layered access and endpoint-security model.

Identity provider and related concepts

Several identity terms describe different parts of the same system.

Conditional access is a downstream control that can use authentication strength, account state, device context and risk. It remains distinct from the IdP's basic role because authorization policy and enforcement may span the IdP, application, gateway and other systems.

The practical model is a trust handoff: the IdP authenticates and makes signed identity statements; the relying party validates those statements and decides what the subject may do. Endpoint, security and lifecycle systems contribute context without becoming the IdP merely because their data influences the decision.