Securing Cloud Identity Federation and SSO: A Practitioner Guide
Identity federation allows a trusted identity provider (IdP) to authenticate users and issue tokens that other services accept. SAML 2.0, OpenID Connect (OIDC), and OAuth 2.0 are the dominant protocols. SolarWinds demonstrated what happens when federation trust is abused at scale: by forging SAML tokens signed with a stolen ADFS certificate, attackers impersonated any user in the target organization across all federated services for months without triggering authentication alerts. Understanding federation security is essential for any organization using cloud SSO.
How Federation Trust Works (and Fails)
Federation creates a chain of trust: your IdP (Okta, Microsoft Entra ID, Ping Identity) authenticates users and issues signed assertions. Service providers (SaaS applications, cloud services) accept these assertions because they trust the IdP's signing key. Attacks on this chain target three points: the signing key itself (steal the SAML signing certificate and forge arbitrary assertions), the assertion validation logic in service providers (exploit parsing vulnerabilities to bypass signature validation), and the federation configuration (add a malicious IdP as a trusted authority). The SolarWinds Golden SAML attack exploited the first vector: attackers extracted the ADFS token signing certificate from a compromised server and used it to forge SAML tokens for any user in the tenant.
SAML Security Hardening
SAML 2.0 is the dominant enterprise SSO protocol despite being over 20 years old. Key hardening controls:
Protect signing certificates aggressively
The SAML signing certificate is the root of trust for all federated authentication. Store private keys in an HSM (Hardware Security Module), not in software key stores. Monitor access to the signing certificate at the HSM level. Rotate certificates annually and immediately upon any suspected compromise.
Enable and validate assertion replay protection
SAML assertions should include a NotOnOrAfter timestamp and AssertionID. Service providers should reject assertions after expiry and reject duplicate AssertionIDs (replay attacks). Verify that all federated applications enforce these checks.
Require signed AuthnRequests
Configure your IdP to require that service provider authentication requests are signed. Unsigned AuthnRequests allow attackers to craft arbitrary requests.
Restrict assertion audiences
SAML assertions include an Audience element that specifies which service provider should accept the assertion. Service providers must validate that the Audience matches their entity ID. Misconfigured SPs that skip audience validation accept tokens intended for other services.
Monitor for ADFS anomalies
If you use on-premises ADFS, monitor for certificate export events (Event ID 70 in ADFS audit logs), new relying party trust additions, and unusual token issuance patterns (high volume, off-hours issuance, tokens for rarely accessed accounts).
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
OAuth 2.0 and OIDC Attack Surface
OAuth 2.0 (authorization) and OpenID Connect (authentication built on OAuth 2.0) power modern application authentication and API access. Common attack patterns:
Authorization code interception
If the redirect_uri in an OAuth flow is not strictly validated, an attacker can redirect the authorization code to an attacker-controlled URL. Mitigation: use PKCE (Proof Key for Code Exchange) for all public clients, validate redirect URIs exactly (no wildcard or prefix matching).
Open redirect in redirect_uri
Some OAuth implementations allow redirect URIs with open redirect vulnerabilities, allowing attackers to redirect authorization codes even when URI validation is present. Mitigation: use only specific, pre-registered redirect URIs; never allow dynamic redirect URIs.
JWT algorithm confusion
If a JWT validation library accepts both asymmetric (RS256) and symmetric (HS256) algorithms, an attacker can change the algorithm header to HS256 and sign the token with the public key (which is often public). Mitigation: validate both the algorithm header and the expected algorithm server-side; never accept algorithm as a trusted field from the token itself.
Refresh token theft
Refresh tokens have long lifetimes and can be used to obtain new access tokens indefinitely. Stolen refresh tokens give attackers persistent access. Mitigation: implement refresh token rotation (invalidate the old refresh token when a new one is issued), detect concurrent use of the same refresh token.
Detecting Federation-Based Attacks
Federation attacks are difficult to detect because the attacker is presenting valid tokens. Detection requires looking for behavioral anomalies in how tokens are used rather than authentication failures:
Token issued without corresponding authentication event
In Golden SAML attacks, forged tokens appear in service provider logs without a corresponding authentication event in the IdP. Correlate IdP authentication events with service provider token acceptance events. Gaps indicate potentially forged tokens.
Unusual token characteristics
Monitor for tokens with unusual validity periods, unusual claim values, or tokens for service accounts that should not be authenticating via federated SSO. Tokens with validity periods longer than your IdP's configured maximum indicate potential forgery.
New federation trust additions
Alert immediately when a new IdP or SAML relying party trust is added to your federation configuration. Attackers who gain admin access to your IdP may add a malicious federation trust to establish persistence.
Off-hours SSO activity for privileged accounts
Federated authentication for privileged accounts (global admins, system administrators) outside of business hours should generate alerts, particularly when accessing sensitive applications.
Multi-IdP and Workforce Federation Risks
Enterprises increasingly federate with multiple identity providers: corporate IdP for employees, partner IdP for B2B access, and individual OIDC providers (Google, Microsoft, Apple) for contractor access. Each federation trust extends your attack surface. Audit all configured federation trusts quarterly: identify the signing certificates and their expiry dates, verify that all trusted IdPs meet your security standards, remove any federation trusts for organizations you no longer work with, and ensure that each federated IdP enforces MFA requirements equivalent to your own.
Hardening SSO Configuration
Beyond protocol-specific controls, these SSO configuration practices reduce federation risk across all protocols:
Enforce MFA at the IdP, not the application
Applications that handle their own MFA enforcement create inconsistent policy. Enforce MFA at the IdP level in your Conditional Access or authentication policy so that all SSO-based access inherits MFA requirements.
Use session duration limits
Short-lived tokens (access tokens: 15 minutes to 1 hour; session tokens: 8 to 24 hours) limit the window of opportunity for stolen token abuse. Avoid indefinite session durations even for internal applications.
Require re-authentication for sensitive operations
Configure step-up authentication requirements for high-risk operations (admin actions, financial transactions, data exports). Even within an authenticated session, sensitive operations should require fresh authentication.
Monitor certificate expiry
SAML federation breaks when signing certificates expire. Implement certificate expiry monitoring with 90-day, 30-day, and 7-day alerts. Certificate expirations cause outages at organizations that do not track them proactively.
The bottom line
Federation trust is an amplified single point of failure: compromise the signing key, compromise every federated application. Protect SAML signing certificates like infrastructure secrets, implement token behavior monitoring to detect Golden SAML attacks, and audit federation trust configurations quarterly to remove stale trusts.
Frequently asked questions
What is the Golden SAML attack?
Golden SAML is an attack technique where an attacker who has stolen an organization's SAML token signing certificate can forge SAML assertions for any user in the organization, impersonating any identity without knowing the user's password or triggering MFA. The technique was used in the SolarWinds breach (2020) and other nation-state campaigns. Detection is difficult because the forged tokens appear legitimate to service providers; defenders must correlate IdP authentication events with service provider token acceptance to identify tokens issued without corresponding IdP authentication.
What is PKCE and why is it required for OAuth?
PKCE (Proof Key for Code Exchange, pronounced 'pixie') is a security extension to the OAuth 2.0 authorization code flow that prevents authorization code interception attacks. The client generates a random code verifier and sends a hash (code challenge) with the authorization request. When exchanging the code for a token, the client sends the original code verifier. The authorization server verifies it matches the challenge. An attacker who intercepts the authorization code cannot exchange it without the original code verifier. PKCE is required for all public clients (mobile apps, single-page applications) and recommended for confidential clients.
How do I detect a compromised SSO session?
Signs of a compromised SSO session: access to applications the user does not normally use, access from a new geographic location or device not seen in the user's history, high-volume data access within the session, access at unusual hours for the user's role, and use of the session token from two concurrent locations. UEBA tools that baseline user behavior and session tokens with continuous access evaluation (Microsoft CAE, Google BeyondCorp) detect these anomalies automatically.
Is SAML or OIDC more secure?
Neither is inherently more secure: both protocols can be implemented securely or insecurely. OIDC is generally considered easier to implement correctly because it is built on OAuth 2.0 with modern cryptography (JWTs, PKCE) and has better tooling support. SAML is more complex, with XML-based assertions and a larger attack surface in parsing logic. For new integrations, OIDC is preferred where supported. SAML remains necessary for many enterprise SaaS integrations that have not added OIDC support.
How often should SAML signing certificates be rotated?
SAML signing certificates should be rotated annually at minimum. Rotation should also occur immediately if: there is any suspected compromise of the certificate or the server hosting it, the certificate is nearing expiry, or there is a security incident affecting the IdP infrastructure. Certificate rotation requires coordination with all relying party applications to update their trusted certificate configuration before the old certificate expires. Test the rotation in a non-production federation environment before executing in production.
What should I log from my IdP for security monitoring?
Key events to capture from your IdP: all successful and failed authentications (with user, timestamp, source IP, device, application), MFA events (challenge issued, challenge passed, challenge failed, MFA method used), administrative events (new user creation, role assignment changes, new application or federation trust additions), credential events (password changes, MFA registration, API key creation), and token issuance events (OAuth token grants, SAML assertion issuances). Feed these into your SIEM and build detections on top of authentication anomalies, not just failures.
Sources & references
- NIST SP 800-63C Digital Identity Federation Guidelines
- Microsoft Identity Platform Security Best Practices
- OWASP OAuth 2.0 Security Best Current Practice
- Okta Security Whitepaper 2025
- SolarWinds SUNBURST Attack Analysis
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.