Identity Provider (IdP)

What is an Identity Provider?

An Identity Provider (IdP) is the system that authenticates users and asserts their identity to other applications. In federated identity and Single Sign-On (SSO), the IdP is the trusted authority that checks who you are — verifying your password, your MFA, your credentials — and then vouches for you to the applications you want to use (the Service Providers), so those apps don’t have to authenticate you themselves. Okta, Microsoft Entra ID (Azure AD), Google, Ping, and Auth0 are IdPs. It’s one half of the two-role SSO model: the IdP proves identity, the Service Provider consumes that proof and grants access.

How it works and why organizations centralize on it

When you log into an app “with your company account” or “Sign in with Google,” here’s the flow: the application (Service Provider) redirects you to the IdP; the IdP authenticates you (password + MFA, or an existing session); and the IdP returns a signed assertion or token — a SAML assertion or an OIDC ID token — attesting to your identity, which the application validates and trusts. The application never sees your password. This is why organizations centralize authentication on an IdP: credentials live in exactly one place instead of being scattered across dozens of apps. That centralization delivers the core benefits — users manage one strong login instead of many (less password reuse and phishing surface), IT enforces MFA and password policy in one spot, and deprovisioning is a single action: disable a departing employee at the IdP and they instantly lose access to every connected app, rather than hunting down individual accounts. The IdP is the backbone of enterprise identity and the foundation of zero-trust “identity as the perimeter” architectures.

The concentration of risk

The flip side of centralizing identity is that the IdP becomes the highest-value single point of failure and attack in the environment — and this is the thing to respect most. If the IdP is down, users can’t log into anything that depends on it, so its availability is business-critical. If the IdP is breached, an attacker potentially gains access to everything it federates — which is exactly why IdPs are prime targets and why attacks increasingly focus on identity (phishing IdP credentials, MFA-fatigue/push-bombing attacks, session-token theft, and tricking users through the IdP’s own flows). This concentration drives the security requirements: the IdP demands the strongest available authentication (phishing-resistant MFA like passkeys/FIDO2, not just SMS codes), careful session management, rigorous monitoring of authentication events, and conditional-access policies. It also places a responsibility on the Service Provider side of the trust: apps must rigorously validate the IdP’s signed assertions (verifying the signature, audience, and expiry), because the entire model’s safety rests on that trust not being forgeable — weak validation lets attackers present forged assertions. The recurring mistakes: treating the IdP like ordinary infrastructure rather than crown-jewel security; relying on weak (phishable) MFA on the one account that unlocks everything; and neglecting the availability planning that a system this central requires.

What people get wrong

• Under-protecting the IdP — it unlocks every federated app, so it needs the strongest, phishing-resistant MFA and the tightest monitoring you have, not baseline security.
• Ignoring availability: because everything depends on it, an IdP outage locks users out of all connected apps — its uptime is business-critical and needs real planning.
• Weak assertion validation on the app side — if Service Providers don’t verify the IdP’s signatures, audience, and expiry, forged identity assertions defeat the whole federation.

Primary source: NIST SP 800-63C: Federation and Assertions