eastbaycyber

What is an identity provider? A Practitioner's Definition

Threat digests 5 min read
EC
East Bay Cyber Editorial Team Reviewed 2026-07-01

TL;DR - An identity provider, or IdP, authenticates users and tells apps who they are. - You use it for SSO, MFA enforcement, and centralized access control. - If you manage business apps, your IdP is a critical security control.

Definition

An identity provider, or IdP, is a service that verifies a user’s identity and provides that identity information to other applications. In practice, it is the system users log into first so they can access multiple apps without separate passwords for each one.

How it works

At a high level, an IdP sits between the user and the application they want to access. Instead of every app maintaining its own username, password, MFA policy, and session logic, the app trusts the IdP to handle authentication.

Here is the usual flow:

  1. A user tries to access an application such as a CRM, VPN portal, cloud console, or internal dashboard.
  2. The application redirects the user to the IdP.
  3. The IdP asks the user to authenticate with a password, passkey, certificate, smart card, or another method.
  4. The IdP may also enforce multi-factor authentication (MFA), device checks, network-based policies, or conditional access rules.
  5. Once the user is verified, the IdP sends a signed response back to the application.
  6. The application validates that response and creates a session for the user.
  7. The user gets access based on the attributes, groups, or roles included in the response.

That signed response is the key idea. The application does not need to see the user’s password. It only needs to trust the IdP’s assertion that the user is who they claim to be.

Common protocols used here include:

  • SAML for browser-based enterprise SSO
  • OpenID Connect (OIDC) for modern web and mobile apps
  • OAuth 2.0 for delegated authorization, often paired with OIDC
  • LDAP or Kerberos in older or internal environments

In most organizations, the IdP also acts as the policy engine for access decisions. That means it can require MFA for admins, block sign-ins from risky locations, deny access from unmanaged devices, or step up authentication for sensitive apps.

Technical Notes

A SAML login flow typically looks like this:

User -> Service Provider (app)
Service Provider -> Identity Provider
Identity Provider -> User login + MFA
Identity Provider -> Signed SAML assertion
Service Provider -> Access granted

An OIDC token set may include:

{
  "iss": "https://idp.example.com",
  "sub": "00u123456789",
  "aud": "client-app-id",
  "email": "user@example.com",
  "groups": ["IT", "VPN-Users"],
  "amr": ["pwd", "mfa"]
}

Admins often validate identity flows by checking browser redirects, token claims, and authentication logs.

When you’ll encounter it

You will encounter an IdP anywhere centralized authentication matters.

For end users, that usually means:

  • Logging into a company laptop and then opening SaaS apps without re-entering passwords
  • Accessing email, HR systems, ticketing tools, VPNs, or file-sharing platforms
  • Using MFA once and then reusing that trusted session across multiple services

For IT and security teams, IdPs show up in day-to-day operations such as:

  • Single sign-on deployment: connecting one identity system to many apps
  • User lifecycle management: onboarding new employees and disabling access when people leave
  • Access reviews: using groups and role mappings to control who can reach what
  • MFA rollout: enforcing stronger authentication in one place instead of app by app
  • Conditional access: allowing or blocking logins based on device state, IP, geography, risk score, or user role
  • Incident response: reviewing authentication logs for suspicious sign-ins, impossible travel, MFA fatigue, or repeated failures

You will also see the term in vendor documentation for cloud services, zero trust projects, and B2B application integrations. Many products ask you to configure an “identity provider” before users can log in with SSO.

For small and midsize businesses, the practical value is simple: an IdP reduces password sprawl and gives admins one place to enforce security controls. Without an IdP, every application becomes its own identity island, which increases help desk load and weakens offboarding.

Technical Notes

Common log events tied to an IdP include:

User authentication succeeded
MFA challenge completed
SAML assertion issued
OIDC token granted
Conditional access policy applied
Login denied due to device noncompliance

Example investigation questions:

- Did the user authenticate at the IdP or locally at the app?
- Was MFA required, and was it satisfied?
- Which groups or roles were sent to the application?
- Was access allowed from an unmanaged device?
- Did the source IP or geolocation match normal behavior?

These terms are closely connected to identity providers and often get confused with them:

  • Authentication: Proving a user is who they claim to be.
  • Authorization: Determining what an authenticated user is allowed to do.
  • SSO (Single Sign-On): Letting one login session provide access to multiple applications.
  • MFA (Multi-Factor Authentication): Requiring two or more authentication factors.
  • Directory service: A system that stores users, groups, and attributes, such as Active Directory or LDAP. An IdP may rely on a directory, but they are not the same thing.
  • Service provider (SP): In SAML, the application that trusts the IdP and consumes its assertions.
  • OpenID Connect (OIDC): A modern identity layer built on OAuth 2.0, commonly used for web and mobile apps.
  • OAuth 2.0: A delegated authorization framework. It is not, by itself, an authentication protocol.
  • Federation: A trust relationship where one system accepts identities verified by another system.
  • Conditional access: Policy-based decisions about whether authentication should be allowed, blocked, or require additional verification.

A useful way to think about it is this: the IdP answers “Who are you?”, while the application answers “What can you do here?” In mature environments, those answers are tightly linked through claims, group membership, device posture, and access policy.

Technical Notes

A simple SAML-style attribute mapping might look like:

<Attribute Name="email">
  <AttributeValue>user@example.com</AttributeValue>
</Attribute>
<Attribute Name="groups">
  <AttributeValue>Finance</AttributeValue>
  <AttributeValue>ERP-Users</AttributeValue>
</Attribute>

A basic OIDC claim mapping example:

email: user@example.com
name: Alex Admin
groups:
  - Security
  - SaaS-Admins
role: administrator

Why it matters to practitioners

An IdP is not just a convenience feature. It is a core control point for identity security. If it is configured well, it improves user experience, strengthens MFA coverage, simplifies offboarding, and gives defenders better visibility into access activity. If it is configured poorly, it can become a single point of failure or a high-value target for attackers.

For practitioners, the main question is not just “Do we have an IdP?” but:

  • Is MFA enforced consistently?
  • Are legacy authentication methods disabled where possible?
  • Are admin accounts separated and protected with stronger policies?
  • Are high-risk sign-ins logged and reviewed?
  • Are app integrations using modern protocols and least-privilege claims?

Those are the operational details that turn an IdP from a login tool into a real security control.

For more information on related security topics, check out our articles on What is SSO? and What is log aggregation?.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Last verified: 2026-07-01

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.