Identity Provider and SSO Security Guide

The identity provider (IdP) is the front door to almost everything, and whoever controls it can sign in as anyone. Single sign-on (SSO) means one login grants access to hundreds of applications, which is good 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 assertion or a rogue federation 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's administrators, authentication, sessions, recovery, integrations and monitoring. It is written for IAM engineers, IdP administrators, security architects and the detection teams who watch identity logs.

Key takeaways

The IdP is a tier-zero system. Protect its administrators, signing keys, federation settings and policies as carefully as domain controllers, because each one can mint access to every connected application.
Attackers target sessions, recovery and trust, not just passwords. Adversary-in-the-middle phishing, cookie theft, MFA fatigue, help desk resets and added federation trusts all bypass a strong password.
Phishing resistance is now the baseline. NIST SP 800-63B-4 requires verifiers to offer at least one phishing-resistant option at AAL2 and requires phishing resistance at AAL3; start with administrators.
Relying parties share the risk. Applications must validate issuer, audience, signature and replay protections; the Storm-0558 investigation found a mail system that skipped issuer and scope validation.
Machine and agent identities live in the IdP too. App registrations, SCIM tokens, service accounts and AI agents need owners, least privilege and monitoring, because attackers use them for persistence.

How SSO and federation work

In SSO the IdP authenticates the user once and then vouches for them to each relying party (RP), usually a SaaS or internal application. Each protocol has different trust anchors and failure modes.

Mechanism	What it does	What an attacker wants
OpenID Connect (OIDC)	IdP issues a signed ID token; the RP validates `iss`, `aud`, signature, expiry and `nonce`	Stolen tokens, weak redirect URI handling, RPs that skip validation
SAML 2.0	IdP sends a signed XML assertion to the service provider	The token-signing certificate, or a new trust they control (Golden SAML)
OAuth 2.0	Delegated access tokens and refresh tokens for APIs	Long-lived refresh tokens, over-broad consented scopes
Federation trusts	One IdP accepts authentication from another (partner, subsidiary, on-premises)	An attacker-controlled source IdP that can assert any user
SCIM provisioning	Creates, updates and removes accounts in applications	The SCIM bearer token, which can create privileged accounts
Sessions	Cookies and refresh tokens at the IdP and each app avoid repeated logins	Session cookies that can be replayed from another device

OIDC Core states that the issuer identifier "MUST exactly match" the iss claim and that the client must check that aud contains its client_id. The OAuth 2.0 Security Best Current Practice (RFC 9700) says public clients must use PKCE, clients should not use the implicit grant, and refresh tokens for public clients must be sender-constrained or rotated. NIST SP 800-63C-4 defines federation assurance levels: at FAL2 the assertion must be strongly protected from injection and audience-restricted to a single RP; at FAL3 the RP also verifies a holder-of-key assertion or bound authenticator, which "protects against the possibility of a compromised IdP". See the OAuth 2.0 and OpenID Connect Guide, the SAML Security Guide and the Federation and Trust Guide.

How identity providers are attacked

Technique	MITRE ATT&CK	Illustration	Primary control
Help desk social engineering	Social engineering, not a single technique	Okta reported callers persuading service desks to reset all MFA factors of Super Administrators	Strong verification for resets; phishing-resistant recovery
MFA fatigue	T1621 Multi-Factor Authentication Request Generation	Uber said a contractor was flooded with 2FA requests until one was accepted	Number matching, then phishing-resistant MFA
Adversary-in-the-middle phishing and cookie theft	T1539 Steal Web Session Cookie	Proxy frameworks such as Evilginx2 capture cookies after MFA	FIDO2 or passkeys; token binding
Rogue federation trust	T1484.002 Trust Modification	Scattered Spider added a federated IdP with automatic account linking (CISA)	Restrict IdP creation; alert on trust changes
Forged SAML tokens	T1606.002 Forge Web Credentials: SAML Tokens	Golden SAML after AD FS compromise (CISA AA21-008A)	Protect signing keys in HSMs; correlate SP logins with IdP events
Signing key theft and weak validation	T1606	Storm-0558 forged tokens with a consumer signing key	Key isolation; RP issuer and scope validation
Hybrid identity and policy tampering	T1556.007 Hybrid Identity, T1556.009 Conditional Access Policies	Okta saw attackers remove second-factor requirements from policies	Protected admin actions; policy change alerts

Incidents show how these play out:

Help desk resets: in the MGM Resorts Breach 2023, the attackers claimed (via vx-underground, as reported by SecurityWeek) that they found an employee on LinkedIn and called the help desk. In the Caesars Entertainment Breach 2023, Caesars confirmed social engineering of an outside IT vendor. See the Account Recovery and Help Desk Security Guide.
MFA fatigue: the Uber Breach 2022 began with a contractor's stolen password and repeated push prompts.
Signing key theft: in the Microsoft Storm-0558 Key Breach 2023, Microsoft's leading hypothesis is that key material left the signing environment in a crash dump and was taken from a compromised engineer's account; the mail system then accepted tokens because developers "did not add the required issuer/scope validation".
Vendor support compromise: in the Okta Support System Breach 2023, Okta says files associated with 134 customers, some of them HAR files containing session tokens, were accessed through a service account whose credentials had been saved to an employee's personal Google profile.
Platform flaws: the Entra ID Actor Token Flaw 2025 (CVE-2025-55241) let a researcher impersonate any user, including Global Admins, in other tenants; the tokens were not subject to Conditional Access and requesting them generated no logs.
Golden SAML: in the SolarWinds Supply Chain Compromise, CISA described forged authentication tokens used to add credentials to service principals in Microsoft cloud tenants.

Hardening the IdP

Administrators

Keep IdP administrators few; use scoped custom admin roles rather than Super Administrator or Global Administrator for daily work.
Use separate, cloud-only admin accounts with phishing-resistant MFA (FIDO2 security keys or device-bound passkeys) from managed devices.
Make privileged roles just-in-time with approval; Okta recommends "dual authorization for JIT" access to more privileged roles. See the JIT Access Guide.
Require re-authentication for sensitive admin actions (for example Okta Protected Actions) and restrict who can create identity providers.
Constrain help desk roles so they cannot reset factors on administrator groups.
Maintain tested break-glass accounts outside normal policies. See the Break-Glass Account Guide.

Authentication

Enforce MFA for all users and block legacy protocols that bypass it.
Move to phishing-resistant authenticators. CISA calls phishing-resistant MFA "the gold standard"; NIST SP 800-63B-4 (final, July 2025) states that OTP and out-of-band methods are not phishing-resistant. See the Phishing-Resistant MFA Guide and the Passwordless and Passkeys Guide.
Where push remains, use number matching, which CISA recommends as an interim control against push bombing.
Use risk-based policies: device compliance, network, impossible travel and sign-in risk.

Sessions and tokens

Level (NIST SP 800-63B-4)	Overall reauthentication timeout	Inactivity timeout	Phishing resistance
AAL2	Should be no more than 24 hours	Should be no more than 1 hour	At least one option must be offered
AAL3	Shall be no more than 12 hours	Should be no more than 15 minutes	Required, with a non-exportable private key

Shorten sessions for admin consoles and sensitive applications; Okta advises admin console policies requiring re-authentication "at every sign-in".
Bind sessions to devices or networks: Microsoft Entra Token Protection accepts only device-bound sign-in session tokens for supported apps, and Okta offers ASN and IP session binding for admin apps.
Use continuous access evaluation so that password resets, account disablement and network changes revoke access in near real time rather than at token expiry.
Revoke sessions on password reset, factor change and suspicious activity. See the Token and Session Security Guide.

Recovery and help desk

Require strong verification for factor resets and recovery: visual or video verification, manager confirmation or in-person checks for privileged users.
Start self-service recovery with the strongest available authenticator and limit it to trusted networks, as Okta recommends.
Notify users of new devices and factor changes, and alert when a reset is followed by a sign-in from a new device or proxy.

Federation, keys and applications

Inventory federation trusts, signing certificates and application integrations; remove unused ones.
Store signing keys in hardware where possible; NIST SP 800-63C-4 requires federal IdPs at FAL2 or higher to protect signing keys with FIPS 140 validated mechanisms.
Alert on any change to federation settings, token lifetimes or signing certificates.
Limit which apps can request which scopes; review admin-consented apps. See the SaaS and OAuth App Governance Guide.

Non-human identities and AI agents in the IdP

The IdP also holds machine identities that are as powerful as admins and far less watched: app registrations with client secrets or certificates, SCIM provisioning tokens, API tokens for automation and service accounts used by integrations. The Okta support breach turned on one such service account. Treat each as a privileged identity with an owner, a purpose, least-privilege scopes, short-lived credentials where supported and alerts on new credentials. See the SCIM Provisioning Guide.

AI agents add a new class. The OpenID Foundation's 2025 whitepaper on agentic AI identity finds that existing SSO and user management tools can support today's simple agents, but that more autonomous agents acting across organisational boundaries will strain current frameworks. Vendors are adding agent-specific constructs: Microsoft Entra Agent ID, for example, gives agents identities to which Conditional Access, risk detection and lifecycle governance can apply. Practical rules: register each agent as its own identity, never let it reuse a human session, prefer delegated tokens that record both user and agent, and keep agent token lifetimes short. See the Agentic AI Identity Guide.

Detection and monitoring

Stream IdP system and audit logs to your SIEM and ITDR tooling, retain them long enough for investigations, and alert on the events below. Okta's own investigation of its support breach found a 14-day detection gap because file downloads produced a different log event type than expected, so test that every alert fires on real events.

Event	Why it matters	Example source
All MFA factors reset for a user, especially an admin	Help desk social engineering pattern	Okta `user.mfa.factor.reset_all`
New identity provider or federation trust created or modified	Persistence and impersonation of any user	Okta `system.idp.lifecycle.*`; AD FS event 307 with 510
SP logins with no matching IdP authentication	Possible forged SAML tokens	CISA AA21-008A Detection Method 1
Admin console access from a new IP and new device, or via anonymising proxy	Hijacked or social-engineered admin	IdP sign-on policy evaluation logs
Session used from a different network or device	Cookie or token replay	Okta `security.session.detect_client_roaming`; Entra risk detections
Admin role assignment, policy change, new app credential	Privilege escalation and persistence	IdP audit log

See the ITDR Guide.

Framework mapping

This is an indicative NHI Mgmt Group alignment, not an official mapping. Control IDs were checked against NIST CSWP 29 (CSF 2.0), the NIST SP 800-53 Rev. 5 OSCAL catalogue, the CIS Controls assessment specification and a published ISO/IEC 27001:2022 Annex A list.

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1
IdP administrator protection	PR.AA-05	AC-2(7), AC-6(5), IA-2(1)	A.8.2, A.8.5	5, 6
Phishing-resistant authentication	PR.AA-03	IA-2, IA-2(8)	A.8.5	6
Assertions, federation and signing keys	PR.AA-04	IA-8, SC-12, SC-23	A.5.17, A.8.24	6
Sessions and reauthentication	PR.AA-03	AC-12, IA-11	A.8.5	4, 6
Recovery and help desk verification	PR.AA-02	IA-5, IA-12	A.5.17	5
Integrations and non-human identities	PR.AA-01	IA-9, AC-6	A.5.16, A.5.18	5, 6
Identity monitoring	DE.CM-03	AU-6, AC-2(12), SI-4	A.8.15, A.8.16	8

Common failure patterns

Strong login, weak recovery: phishing-resistant MFA at sign-in, but a help desk can reset it after a phone call. This is the Scattered Spider pattern CISA describes.
Admins on ordinary accounts: Super Administrator rights on a user's everyday identity, signed in from unmanaged devices.
Federation nobody watches: the ability to add an identity provider is unrestricted and generates no alert, so an attacker can quietly assert any user.
Relying parties trusting too much: apps that accept any validly signed token without checking issuer, audience or scope, as in Storm-0558.
Bearer sessions everywhere: long-lived cookies and refresh tokens with no device binding, so one stolen HAR file or infostealer log is enough.
Logs that miss the path used: detections tuned to one event type while the attacker generates another, as in Okta's 14-day gap.
Integration credentials without owners: SCIM tokens and app secrets created years ago with broad scopes and no rotation.

Metrics that show progress

Metric	What it shows	Target direction
Administrators using phishing-resistant MFA from managed devices	Tier-zero protection	Up, to 100%
Users enrolled in phishing-resistant authenticators	Exposure to AiTM and push fatigue	Up
Standing Super Administrator or Global Administrator assignments	Attack surface of the IdP	Down
Privileged factor resets with documented strong verification	Help desk resilience	Up, to 100%
Federation trusts and app integrations with a named owner, reviewed in 12 months	Trust hygiene	Up
Applications on legacy authentication or without SSO	Gaps outside IdP policy	Down
Median time from factor reset or trust change to analyst review	Detection speed	Down

Implementation roadmap

Phase	Actions	Exit criteria
First 30 days	Inventory admins, federation trusts, signing certificates, app registrations and SCIM tokens; move admins to separate accounts with FIDO2; restrict IdP creation; turn on alerts for factor resets and trust changes	All admins phishing-resistant; tier-zero alerts live and tested
Days 31 to 90	Harden help desk verification; enable number matching; block legacy authentication; bind admin sessions; enable continuous access evaluation; JIT for top roles	No standing top-level admin except break-glass; recovery flow documented and tested
Days 91 to 180	Roll out passkeys or FIDO2 to all users; review relying party validation; assign owners to integrations and agents; rotate or remove stale app credentials; run a help desk social engineering exercise	Metrics trending; integrations owned; exercise findings closed

Practitioner checklist

Treat the IdP as tier zero; minimise, separate and scope admin accounts.
Enforce phishing-resistant MFA for administrators now and plan it for all users.
Block legacy authentication; use number matching wherever push remains.
Require strong verification for factor resets and limit help desk roles over admins.
Restrict who can create identity providers and alert on every trust change.
Protect signing keys in hardware and alert on certificate or token lifetime changes.
Check that relying parties validate issuer, audience, signature and replay protections.
Shorten and bind sessions; enable continuous access evaluation.
Give every app registration, SCIM token and AI agent an owner and least-privilege scopes.
Stream IdP logs to detection tooling and test each identity alert.
Maintain tested break-glass access.