Identity Provider and SSO Security Guide

The identity provider (IdP) is the front door to almost everything. Single sign-on (SSO) means one login grants access to hundreds of applications, which is excellent for users and for control, and makes the IdP one of the most valuable targets an attacker can reach. A compromised administrator, a stolen session token, a forged federation token or a misconfigured trust can turn one foothold into access across the enterprise. This guide explains how SSO and federation work, how identity providers are attacked, and how to harden the IdP, its administrators, its sessions and its integrations.

Key takeaways

The IdP is a tier-zero system: protect its administrators, signing keys and configuration as carefully as domain controllers.
Modern attacks target sessions and tokens rather than passwords: adversary-in-the-middle phishing, session cookie theft, token replay and help-desk social engineering.
Use phishing-resistant MFA for administrators and, increasingly, all users; bind and shorten sessions; and monitor for token misuse.
Federation trusts and application integrations are identities too. Review them, limit them and watch them.

How SSO and federation work

OpenID Connect (OIDC) and SAML 2.0 let applications rely on the IdP to authenticate users. The IdP issues a signed token or assertion that the application trusts.
Sessions at the IdP and at each application are maintained with cookies and tokens, so users do not re-authenticate every time.
Federation lets one IdP trust another, for example a partner's or a legacy on-premises IdP.
Provisioning (often via SCIM) creates and updates accounts in applications.

Every trust relationship and signing key is a point where an attacker can impersonate users if it is compromised.

How identity providers are attacked

Help-desk social engineering: attackers call the service desk posing as employees to reset MFA or passwords, as in the MGM Resorts and Caesars breaches.
Adversary-in-the-middle phishing that captures session cookies after MFA completes.
MFA fatigue: repeated push prompts until a user approves, as in the Uber breach.
Token and signing key theft: a stolen signing key lets attackers forge tokens, as in the Microsoft signing key incident.
IdP vendor and support compromise: the Okta support system breach exposed files containing session tokens.
Tenant and configuration flaws: the Entra ID tenant flaw showed how platform weaknesses can have wide impact.
Malicious federation or app registration: attackers with admin access add a federated IdP or a new application credential for persistence.
Password spraying against accounts without MFA, especially legacy and test accounts.

Hardening the IdP

Administrators

Keep the number of IdP administrators small; use role-scoped admin roles instead of super-admin.
Use separate, cloud-only admin accounts with phishing-resistant MFA (FIDO2 security keys or platform passkeys).
Use just-in-time elevation for admin roles, with approval. See the JIT Access and Zero Standing Privilege Guide.
Require privileged access workstations or compliant devices for admin sessions.
Maintain tested break-glass accounts. See the Break-Glass Account Guide.

Authentication

Enforce MFA for all users and remove legacy authentication protocols that bypass it.
Move towards phishing-resistant authenticators. NIST SP 800-63B-4 (2025) requires services to offer at least one phishing-resistant option at AAL2 and requires phishing resistance at AAL3. See the Passwordless and Passkeys Guide.
Use number matching and context in push notifications, and limit prompt frequency.
Use risk-based policies: device compliance, location, impossible travel and sign-in risk.

Sessions and tokens

Shorten session lifetimes for sensitive applications and admin roles.
Bind sessions or tokens to devices where the platform supports it, to make stolen cookies less useful.
Use continuous access evaluation so revocation takes effect quickly.
Revoke sessions on password reset, MFA change and suspicious activity.

Recovery and help desk

Require strong identity verification for MFA resets and account recovery, such as video verification, manager approval or in-person checks for privileged users.
Alert on MFA method changes followed by sign-ins from new devices.

Federation, keys and applications

Inventory federation trusts, signing certificates and application integrations; remove unused ones.
Protect and rotate signing keys; alert on any change to federation settings or token signing certificates.
Limit which applications can request which scopes and claims; review admin-consented apps. See the SaaS and OAuth App Governance Guide.
Protect provisioning (SCIM) tokens, which are powerful NHIs.

Monitoring

Stream IdP logs to your SIEM and ITDR tooling.
Alert on admin role assignment, MFA resets, new federation trusts, new app credentials, policy changes and token replay indicators.
See the ITDR Guide.

Practitioner checklist

Treat the IdP as tier zero; minimise and separate admin accounts.
Enforce phishing-resistant MFA for administrators and plan it for all users.
Remove legacy authentication; enforce MFA everywhere.
Harden help-desk verification for MFA and password resets.
Shorten and bind sessions; enable continuous access evaluation.
Inventory and monitor federation trusts, signing keys and app credentials.
Stream IdP logs to detection tooling with identity-specific alerts.
Maintain tested break-glass access.