What Is IdP Security? Securing Your Identity Provider

Compromise one identity provider and an attacker does not break into one application. They get a key to every application that trusts it. The IdP is the single system that decides who a user is and issues the token everything downstream accepts, which is exactly why it sits at the top of an attacker's target list.

Identity provider (IdP) security is the practice of protecting that system: the service that authenticates users and issues the assertions other applications rely on to grant access. This guide explains what an IdP is, how authentication, authorization, and single sign-on actually work through it, why the IdP is a high-value target, and the controls that keep it from becoming a single point of total compromise. It is written for defenders who have to monitor an IdP, scope an incident that touches one, or harden a tenant before an attacker tests it for them.

What is an identity provider (IdP)?

An identity provider is a service that authenticates a user and asserts that identity to other applications, so those applications do not each have to manage passwords themselves. The user proves who they are once to the IdP. The IdP then issues a signed token, and every application configured to trust the IdP accepts that token as proof of identity.

This is the model behind Okta, Microsoft Entra ID, Google Workspace, Ping Identity, and on-premises systems such as Active Directory Federation Services. The applications, called service providers or relying parties, never see the user's credentials. They see an assertion the IdP signed, read the identity and attributes it carries, and start a session.

An IdP manages more than human logins. It authenticates employees, contractors, and partners, and increasingly it governs non-human identities too: service accounts, automation, bots, and workloads that need to authenticate to APIs. Those non-human accounts are often the weakest part of an identity estate because they carry static secrets, rarely use multi-factor authentication, and are seldom reviewed.

The IdP concentrates trust on purpose. That concentration is its value, one place to manage identity, one place to enforce policy, and its risk, one place that, if breached, unlocks everything that trusts it.

How an IdP works

An IdP does three jobs: it authenticates the user, it decides what that user is allowed to reach, and it lets one login carry across many applications. Walk a single sign-in through it and the moving parts become clear.

Authentication. The user proves identity to the IdP. That can be a password, a multi-factor prompt, a passkey or other FIDO2 authenticator, biometrics, or a certificate. The IdP, not the application, owns this step, which is why a single strong authentication policy at the IdP protects every connected app at once.

Authorization and access control. A verified identity is not the same as unrestricted access. After authentication, the IdP and the application apply policy: group memberships, roles, and attributes determine which resources the user can reach. Modern IdPs also evaluate context at this point, device posture, location, sign-in risk, through conditional access policies that can require step-up authentication or block the session outright.

Single sign-on (SSO). Once the user is authenticated, the IdP issues a token the user can present to other trusting applications without logging in again. One authentication, many applications. SSO is the convenience that drives IdP adoption, and it is also why a stolen IdP session is so valuable: it can unlock the full set of federated apps, not just one.

The federation protocols

An IdP talks to applications over open federation protocols so it can authenticate to apps that are not on the same platform. Three matter most:

• SAML 2.0 (Security Assertion Markup Language). An XML-based standard for web SSO. The IdP signs a SAML assertion with its private key, and the service provider validates that signature against the IdP's public certificate. SAML is widespread in enterprise SaaS.
• OAuth 2.0. An authorization framework. It issues access tokens that let an application act on a user's behalf against an API. OAuth handles delegated authorization, not authentication by itself.
• OpenID Connect (OIDC). An identity layer built on top of OAuth 2.0. It adds an ID token (a signed JWT) that carries who the user is, which is what makes OAuth usable for sign-in. Most modern app and mobile authentication uses OIDC.

The common thread across all three: the application trusts the user because it trusts a token the IdP signed. Whoever can produce a token the application accepts, by stealing the signing key, hijacking a session, or tricking the user, controls access. That single fact frames every risk below.

Why the IdP is a high-value target

The IdP is attractive for the same reason it is useful. It is the chokepoint for access. Several distinct attack paths converge on it.

Phishing and credential theft. The most common entry point is still tricking a user out of their credentials. A convincing phishing page that mimics the IdP login captures the username, password, and, with an adversary-in-the-middle proxy such as Evilginx, the post-MFA session cookie. The same goal drives credential theft through infostealer malware that scrapes saved sessions and tokens from the browser. A stolen live session token bypasses the password and the MFA prompt because both already happened.

MFA fatigue and push bombing. When an account has push-based MFA, attackers who already hold the password spam the user with approval prompts until one is accepted out of annoyance or confusion. The Lapsus$ group and others used this technique to defeat MFA on real tenants. It works because the second factor is a yes/no tap, not a proof of presence.

Token and key theft (federation abuse). If an attacker reaches the IdP's signing key, they stop needing user credentials at all. They forge their own tokens for any user, with any claims, including a claim that MFA was satisfied. Golden SAML is this attack against SAML federation: steal the token-signing certificate from an on-premises AD FS server and mint assertions Microsoft 365 accepts. The 2020 SolarWinds intrusion used exactly this path to move from on-premises into cloud identity.

Consent phishing and OAuth abuse. Instead of stealing a password, the attacker tricks the user into granting a malicious OAuth application access to their account. The user clicks "allow," and the app receives a refresh token that survives password resets and many MFA changes. No credential ever changes hands.

Privileged account and admin compromise. An attacker who reaches an IdP administrator can create accounts, weaken MFA policy, add a rogue federation trust, or register a backdoor app. This is the worst case: control of the IdP control plane itself, from which every other attack becomes trivial.

The common consequence across these paths is scope. A foothold in one endpoint compromises one machine. A foothold in the IdP compromises identity, and through it every application, dataset, and admin console that identity can reach.

How to secure an identity provider

IdP security is layered. No single control stops every path above, so the goal is to remove the easy wins, raise the cost of the hard ones, and detect the forge or hijack you cannot prevent.

Enforce phishing-resistant MFA. Move privileged and high-value accounts off SMS and push approvals onto FIDO2 passkeys or certificate-based authentication. Phishing-resistant factors are bound to the legitimate domain, so an adversary-in-the-middle proxy cannot relay them and push bombing has nothing to spam. This is the single highest-impact control.

Apply conditional access and continuous evaluation. Use conditional access policies to gate sign-ins on device compliance, managed-network or location signals, and real-time sign-in risk, with step-up or block on anomalies. Pair it with continuous access evaluation so a revoked or risky session is killed mid-stream rather than living until the token expires.

Protect the signing keys and the admin plane. Treat the IdP control plane as Tier 0. Keep token-signing certificates off general-purpose servers where possible, restrict and audit every certificate operation, require phishing-resistant MFA and privileged access workflows for admin roles, and review every federation trust and high-privilege OAuth grant. For on-premises federation such as AD FS, monitor the server like a domain controller, since the signing key is a file an attacker can steal.

Govern non-human and OAuth identities. Inventory service accounts and registered applications, rotate or eliminate static secrets, scope OAuth grants to the minimum needed, and revoke unused or over-permissioned consents. Consent phishing dies when users cannot grant tenant-wide access and admins review what apps can do.

Right-size privilege and review it. Apply least privilege and just-in-time elevation so a compromised account holds the fewest standing rights possible. Regular access reviews remove the dormant admin rights and stale group memberships that turn a minor compromise into a major one.

Monitor identity as a primary signal. Centralize IdP sign-in and audit logs into the SIEM and alert on the patterns that precede or reveal compromise: impossible-travel sign-ins, MFA-method changes, new federation trusts, anomalous token lifetimes, and cloud sign-ins with no matching on-premises authentication event (the tell for a forged federation token). The forge itself is often silent; the activity around it is not.

Where IdP security fits in the bigger picture

An IdP secures access, but it does not see everything. It knows who authenticated and what policy applied; it does not by itself watch what each connected SaaS app does with that access afterward, or whether an application's own configuration drifts into a risky state. That gap is why identity security pairs with SaaS security posture management (SSPM) and broader identity threat detection: the IdP enforces the front door, and posture management watches the rooms behind it.

The practical takeaway for a defender is to treat the IdP as critical infrastructure on the level of a domain controller. It is the system that issues trust. Harden the authentication, protect the keys and the admin plane, govern the non-human and OAuth identities that slip through the cracks, and monitor identity as a first-class telemetry source. The IdP's whole value is that everything trusts it, which is precisely why everything depends on keeping it secure.

Frequently Asked Questions

What is an identity provider (IdP)?

An identity provider is a service that authenticates a user and asserts that identity to other applications, so those applications do not manage passwords themselves. The user proves identity once to the IdP, which issues a signed token that every trusting application accepts. Okta, Microsoft Entra ID, Google Workspace, and Active Directory Federation Services are common examples.

What is IdP security?

IdP security is the practice of protecting the identity provider and the authentication, authorization, and single sign-on it controls. Because every connected application trusts the tokens the IdP issues, securing the IdP means protecting its credentials, signing keys, admin plane, and policies so a single compromise cannot unlock every downstream app.

Why is an identity provider a high-value target?

The IdP is the chokepoint for access: a foothold in it can unlock every application, dataset, and admin console that trusts it, not just one system. Attackers reach it through phishing and stolen sessions, MFA fatigue, signing-key theft such as Golden SAML, OAuth consent phishing, and admin compromise. The shared consequence is scope, which is what makes the IdP worth attacking.

What protocols do identity providers use?

Identity providers use open federation protocols so they can authenticate to applications on any platform. SAML 2.0 is an XML standard for web single sign-on, OAuth 2.0 is an authorization framework that issues access tokens, and OpenID Connect adds an identity layer on top of OAuth that carries who the user is in a signed ID token. The application trusts the user because it trusts a token the IdP signed.

What is the best way to secure an IdP?

The highest-impact control is phishing-resistant MFA, such as FIDO2 passkeys or certificate-based authentication, on privileged and high-value accounts, because it defeats phishing proxies and push bombing. Layer conditional access with continuous evaluation, treat the signing keys and admin plane as Tier 0 infrastructure, govern OAuth and non-human identities, apply least privilege, and monitor IdP logs in the SIEM.

What is MFA fatigue and how does it relate to IdP security?

MFA fatigue, also called push bombing, is when an attacker who already has a user's password spams repeated push approval prompts until the user accepts one. It defeats push-based MFA because the second factor is a simple yes/no tap. The defense is phishing-resistant MFA bound to the legitimate domain, such as FIDO2, which has no prompt to spam.

What is Golden SAML?

Golden SAML is an attack where an adversary steals the token-signing certificate from a SAML identity provider, typically an on-premises AD FS server, and forges SAML assertions for any user with any claims, including a claim that MFA was satisfied. Because the attacker signs the tokens, the access bypasses passwords and MFA and produces no normal authentication event. It was used in the 2020 SolarWinds intrusion.

The bottom line

An identity provider authenticates users and issues the tokens that every connected application trusts. That concentration of trust is its purpose and its danger: compromise the IdP and you compromise identity itself, and through it every app, dataset, and console that identity reaches.

IdP security is about defending that chokepoint. Phishing-resistant MFA, conditional access, Tier 0 protection of the signing keys and admin plane, governance of OAuth and non-human identities, least privilege, and identity-centric monitoring are the controls that keep one stolen login or one forged token from becoming total compromise. Treat the IdP like the critical infrastructure it is, because attackers already do.