Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Single Sign-On centralizes authentication for dozens or hundreds of applications behind one Identity Provider (IdP), so users authenticate once and are federated into every connected Service Provider (SP) or Relying Party (RP) via SAML, OIDC, or OAuth. The usability and governance gains are substantial — one place to enforce MFA, one place to deprovision a leaving employee — but they come with a concentration-of-risk trade-off: the IdP becomes the single highest-value target in the environment, because compromising it (or the trust relationship between it and an SP) can yield access to every downstream application at once.
SSO threats therefore fall into two broad categories: attacks on the IdP itself (credential theft, session/token theft, administrative console compromise) and attacks on the federation trust relationship between IdP and SP (weak validation on the SP side, unsolicited/IdP-initiated response abuse, token replay across services that share a validation bug). Hardening has to address both — a perfectly secured IdP does not help if every SP behind it trusts assertions carelessly.
Attack Prerequisites
Meaningfully compromising an SSO deployment generally requires one of:
- IdP credentials obtained without a phishing-resistant second factor — the highest-leverage target in the environment, since IdP access often cascades into every connected application.
- An SP that performs incomplete token/assertion validation — missing or substring-based issuer/audience checks, no
InResponseTocorrelation, or acceptance of IdP-initiated SSO without any binding to a request the SP actually made. - Stale sessions with no coordinated Single Logout (SLO) — a session left valid at one SP after the user’s access was revoked at the IdP, especially on shared or unmanaged devices.
- A misconfigured or over-trusted federation relationship — a test or staging SP registered with the same trust as production, or a wildcard/broad redirect URI that widens where tokens can be sent.
How It Works
Enterprise SSO architecture centers on a broker: the IdP (Okta, Microsoft Entra ID, Ping, or similar) holds the actual authentication event and issues signed assertions or tokens that each SP trusts based on pre-established metadata (SAML) or client registration (OIDC/OAuth). Conditional access policies — device compliance, network location, risk score — are enforced once, centrally, at the IdP, and every connected SP inherits that enforcement without implementing it itself. This is the point of SSO, and also exactly why the IdP is a single point of both control and failure.
Trust between IdP and SP is established out-of-band — SAML via exchanged metadata (entity IDs, certificates, ACS URLs) and OIDC via client registration (client ID/secret, redirect URIs, allowed scopes). The SP’s job is to verify, on every response, that the assertion or token actually came from the expected IdP (issuer), is intended for this specific SP (audience), was issued for the request this SP actually made (correlation via InResponseTo or state/nonce), and has not expired. Any weakening of these checks — often introduced by developers debugging integration issues and never tightened back up — reopens the exact trust boundary SSO depends on.
Federation chains can also nest: an SP can itself act as an IdP for further downstream systems, or an organization can broker multiple external IdPs (partners, acquisitions) through one internal hub. Each additional hop is another place where an issuer/audience check can be implemented loosely, and a flaw at any hop can propagate trust further than intended.
Vulnerable Code / Configuration
A frequent real-world gap is an SP validating the token issuer with a substring or prefix match instead of exact string equality — intended to tolerate minor URL variations, but exploitable if an attacker can register or control a domain that merely contains the expected issuer string:
// VULNERABLE: substring match instead of exact comparison.
function validateIssuer(tokenIssuer) {
return tokenIssuer.includes('idp.corp.example');
}
// Passes for the legitimate issuer, but ALSO passes for:
// https://idp.corp.example.attacker.io/
// https://evil-idp.corp.example.malicious.net/
// FIXED: exact match against the known-good issuer value.
function validateIssuer(tokenIssuer) {
return tokenIssuer === 'https://idp.corp.example/';
}
Equally common on the SAML side: an SP configured to accept IdP-initiated SSO (no AuthnRequest was ever sent, so there is nothing to correlate) with no additional restriction, meaning any validly signed assertion from the trusted IdP is accepted for login at any time, from any origin, with no CSRF-style state binding:
<!-- SP configuration accepting unsolicited responses with no
InResponseTo check possible (there was no original request)
and no additional context binding -- relies entirely on the
signature and audience restriction for security. -->
<md:SPSSODescriptor AuthnRequestsSigned="false" ...>
<md:AssertionConsumerService index="0" isDefault="true"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Location="https://sp.corp.example/saml/acs"/>
</md:SPSSODescriptor>
Walkthrough / Exploitation
Assessing an SSO deployment starts with enumerating the trust surface — every SP registered against the IdP, since a single weak SP can be the entry point even if the IdP and every other SP are solid:
1. Enumerate the SP catalog (IdP admin console access, or the
organization's app portal / SAML metadata endpoints).
2. For each SP, capture a login and inspect issuer/audience
validation: does changing the audience in a test assertion get
rejected? Does a near-miss issuer string get accepted?
3. Test whether IdP-initiated login is accepted with no prior
SP-side request, and whether that response can be replayed.
4. Test session behavior after IdP-side revocation: does an
existing SP session survive until its own timeout, or is it
terminated by Single Logout / a back-channel signal?
Also test the adjacent, increasingly common threat of device-code phishing: an attacker starts an OAuth device authorization flow against the real IdP, then sends the victim the legitimate user-facing verification URL and code via a pretext (“approve this Teams meeting device”); if the victim completes it, the attacker’s device receives a fully valid, SSO-wide token without ever touching a phishing clone of the login page.
Note: A flaw in one SP’s validation logic is a whole-organization risk under SSO in a way it would not be for a standalone application — if two SPs share the same weak audience-validation code (a common internal library), an assertion crafted to pass one may pass the other, effectively creating cross-application privilege escalation through the shared trust anchor.
Opsec: IdP admin console access is Tier-0 equivalent — any assessment activity that touches IdP configuration (adding a test SP, modifying trust settings) should be tightly scoped, logged, and reverted immediately, since a mistake here has organization-wide blast radius.
Detection and Defense
- Enforce phishing-resistant MFA at the IdP for all users, especially administrators, since the IdP is the highest-value single target.
- Validate issuer and audience with exact string comparison, never substring or prefix matching, on every SP.
- Prefer SP-initiated flows with
state/nonce/InResponseTocorrelation over unrestricted IdP-initiated SSO where possible. - Implement Single Logout (SLO) or short session lifetimes at SPs so IdP-side revocation actually terminates access promptly rather than waiting out a long SP session timeout.
- Monitor IdP admin console changes and anomalous sign-ins (impossible travel, new device plus new SP access in quick succession) and disable legacy, non-MFA-capable authentication protocols entirely.
Real-World Impact
Okta’s own 2023 disclosure of a breach of its customer support system — in which session tokens uploaded by customers for troubleshooting were later abused to access a subset of customer tenants — is a well-documented, vendor-confirmed illustration of how concentrated the risk becomes when an IdP itself is compromised. Because SSO is specifically designed so one credential or one token reaches many applications, incidents at the identity layer consistently produce far larger blast radii than a compromise of any single downstream application.
Conclusion
SSO trades many small attack surfaces for one large, well-defended one — which is a good trade only if that one surface, the IdP and every SP’s trust validation of it, is actually held to a correspondingly higher standard. Phishing-resistant MFA at the IdP, exact-match issuer/audience validation at every SP, and prompt session revocation on logout or compromise are what keep the convenience of “log in once” from becoming “compromise once, own everything.”
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments