Helpful first: OIDC and SAML assertions: signed identity claims are not admin permission
Key points
- Identify and prevent the five OIDC and SAML validation failures at the Relying Party boundary
- Explain how XML Signature Wrapping (XSW) and JWT algorithm confusion (
alg: none/ RS256-to-HS256) bypass naive verifiers - Isolate multi-tenant Identity Providers so a compromised partner IdP cannot assert identities for another tenant
When a federated trust bridge turns into a highway for attackers
Federation concentrates authentication trust at the boundary between an Identity Provider (IdP) and a Relying Party (RP). When configured properly, it eliminates password sprawl across Meridian Space & Robotics (chronos.). When the Relying Party cuts corners on validation, however, an attacker does not even need to steal a user’s password or hardware key - they can forge or replay an assertion directly against the RP’s callback endpoint.
Principal Security Architect Vera Vance and Staff Infrastructure Engineer Kael Cho audit every OIDC and SAML integration at Meridian against five federation failure modes.
| Failure Mode | What Goes Wrong in the Code | Exploit Outcome | Mandatory Engineering Defense |
|---|---|---|---|
1. Signature Bypass (jwt. / alg: none / XSW) | RP parses claims without verifying signature, accepts alg: none, or validates SAML signature on one XML node while reading <NameID> from an unsigned injected sibling (XML Signature Wrapping) | Attacker mints arbitrary admin assertions out of thin air | Enforce strict algorithm allowlist (RS256/ES256) against pinned JWKS; canonicalize XML and read identity only from the exact signed DOM subtree |
2. Cross-Tenant Issuer (iss) Confusion | Multi-tenant RP trusts any configured IdP to assert users for any customer domain or accepts wildcard OIDC issuers | Compromised partner IdP (LakeAuth) logs in as ceo@chronos. | Bind each tenant domain strictly to its registered (tenant_ and JWKS endpoint |
3. Audience (aud) Replay | RP verifies signature and issuer but ignores aud / <AudienceRestriction> | Token minted for a low-security staging wiki is replayed to hijack the production flight console | Require exact match between token aud and this RP’s unique client_ / EntityID |
4. Clock & Replay Neglect (exp, nonce, InResponseTo) | RP ignores expiration timestamps or allows the same signed SAML response / OIDC nonce to be posted repeatedly | Captured assertion from a shared log is replayed hours or days later | Enforce tight clock-skew bounds (<= 60s), strict exp/NotOnOrAfter, and one-time cache eviction of assertion IDs |
5. Unverified Account Linking (email collision) | RP auto-merges a newly federated login into an existing local account whenever email strings match, without checking email_ or domain ownership | Pre-account takeover or cross-IdP account hijacking | Key accounts on (iss, sub) and require re-authentication of the target account before linking a new federated identity |
Exploit Outcome
1. Signature Bypass
Attacker mints arbitrary admin assertions out of thin air
2. Cross-Tenant Issuer (iss) Confusion
Compromised partner IdP (LakeAuth) logs in as ceo@chronos.orbital
3. Audience (aud) Replay
Token minted for a low-security staging wiki is replayed to hijack the production flight console
4. Clock & Replay Neglect
Captured assertion from a shared log is replayed hours or days later
5. Unverified Account Linking
Pre-account takeover or cross-IdP account hijacking
Not needed
a user’s password or hardware key
Deep dive: JWT algorithm confusion and XML Signature Wrapping (XSW)
Two cryptographic parser bugs deserve special attention from security engineers. In JWT Algorithm Confusion, the server expects tokens signed asymmetrically with RS256 (verified using the IdP’s public RSA key), but a buggy library honours the alg: "HS256" header inside the untrusted token. The attacker signs a forged token using HS256 (HMAC) with the IdP’s public RSA key bytes as the HMAC secret - and the server verifies it using that same public key string! Always hardcode the permitted asymmetric algorithms in the verifier options.
In SAML XML Signature Wrapping (XSW), the IdP signs <saml:Assertion ID="legit">. The attacker intercepts the XML, moves the signed <Assertion ID="legit"> into an ignored extension element so the signature check still passes, and inserts a second, unsigned <saml:Assertion ID="evil"> at the top of the document containing <NameID>vera.. If the XML parser verifies the signature by ID reference but extracts the logged-in user via document., the attacker logs in as Vera.
Blast-radius containment when a partner IdP is compromised
Even when every cryptographic signature check is flawless, remember what federation trust means: you are trusting the issuer to tell the truth about its domain. If Meridian federates with an external logistics vendor (vendor-), Meridian’s Relying Party must enforce domain-scoped issuer pinning: the vendor- IdP may only assert identities whose domain belongs to vendor- and may only map to external partner roles, never @chronos. employee accounts.
Issuer
vendor-x.example
Control
domain-scoped issuer pinning
Allowed
external partner roles
Refused
@chronos.orbital employee accounts
Signing key
Golden SAML. With a stolen IdP private signing key, an attacker can mint valid SAML assertions or OIDC JWTs until the signing certificate is rotated. Pinning still limits a compromised vendor-x.example IdP to its own domain.
CHECK YOUR JUDGMENT