An identity provider (IdP) is a system that creates, stores, and manages digital identities—serving as the authoritative source for authentication across the applications connected to it.

‍

Main takeaways

• The IdP is the foundation of modern access management: it's the central point where authentication is verified, policies are enforced, and access is granted or denied.
• The value of an IdP depends heavily on its coverage—applications that aren't connected to the IdP fall outside its visibility and control.
• In most organizations, the IdP manages a subset of the actual identity landscape; significant access happens through accounts and integrations that exist outside its scope.
• Understanding the gap between what the IdP sees and what's actually in the environment is essential for accurate identity risk assessment.

What is an identity provider?

An identity provider (IdP) is a service that manages digital identity: it stores user credentials and attributes, verifies that users are who they claim to be (authentication), and communicates that verified identity to other applications (federation). When you log into a work application and it redirects you to a central login page rather than asking for its own credentials, that central login is handled by an IdP.

‍

Modern enterprise IdPs—products like Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, and JumpCloud—serve as the hub of an organization's identity infrastructure. They handle authentication for connected applications, enforce security policies (like MFA requirements and session timeouts), support provisioning and deprovisioning workflows, and provide audit logs of authentication events.

‍

IdPs typically work alongside or enable two key standards: SAML (Security Assertion Markup Language) and OIDC (OpenID Connect), which define how identity assertions are communicated between the IdP and the applications relying on it.

‍

How identity providers work

The core function of an IdP in an enterprise context follows a pattern:

‍

A user attempts to access an application. The application redirects the user to the IdP for authentication. The IdP verifies the user's credentials—username and password, MFA, or both—and, if successful, issues a token asserting the user's identity. The application accepts that token and grants access accordingly.

‍

This model, called federated identity or Single Sign-On (SSO), has several important benefits: users authenticate once rather than maintaining separate credentials for every application; IT has a single place to enforce authentication policy; and a centralized audit log captures authentication activity across all connected applications.

‍

The IdP is also the natural control point for provisioning: when a new employee is onboarded, their IdP account is created, and that account propagates access to connected applications. When they leave, disabling the IdP account—in theory—removes their access across the board.

‍

The limits of IdP coverage

In theory, the IdP model provides comprehensive visibility and control. In practice, its coverage is limited by what's connected to it.

‍

Applications that connect to the organization's IdP via SSO are within scope. The IdP can authenticate access to them, enforce policy on them, and deprovision access to them when an employee leaves. But:

• Many SaaS applications employees use were never connected to the IdP. They were signed up for independently, using a work email address and a standalone credential. The IdP has no visibility into them.
• OAuth integrations between SaaS applications create access relationships that bypass the IdP entirely. One application granting another access to organizational data doesn't require IdP authentication.
• Non-human identities—service accounts, API keys, automation credentials—typically aren't managed through the IdP at all.

The result is that the IdP's view of the identity landscape is authoritative within its scope and blind outside it. The actual identity landscape is consistently larger and more complex than what any single IdP shows.

‍

The IdP coverage gap

Understanding the boundary of IdP coverage is important for security teams because the gap between "what the IdP knows about" and "what's actually in the environment" is exactly where risk accumulates.

‍

An employee deprovisioned in the IdP may still have active accounts in SaaS tools they signed up for outside SSO. A compromised credential for a non-SSO application doesn't trigger any IdP-level alerts. An OAuth grant that an employee authorized before leaving doesn't get cleaned up when their IdP account is disabled.

‍

Closing this gap requires discovery capabilities that can surface the full account and integration landscape—not just what's been formally connected to the IdP—and governance processes that cover the complete picture.

‍

Learn how Nudge Security surfaces the identity and access landscape beyond your IdP's scope →