auditing-saml-and-oidc-federation-trust

Auditing SAML and OIDC federation trust: the assertion is only as good as its verification

Federated login moves the authentication decision to an identity provider and hands the relying party a signed assertion, a SAML response or an OIDC ID token, that says who the user is. The relying party's entire security then rests on verifying that assertion correctly, and the ways to verify it incorrectly are well worn. SAML signature wrapping slips an unsigned, attacker-authored assertion alongside a signed one so the application reads the wrong element; a signature checked over the wrong scope, or not at all, accepts a tampered response. An OIDC ID token whose issuer, audience, or nonce goes unchecked can come from the wrong provider, be minted for a different application, or be replayed. And a relying party that trusts a subject or email in the assertion without binding it to the verified issuer will authenticate any user an attacker names. The audit is not whether federation is configured but whether a forged or misbound assertion is refused. You audit this by testing each validation the relying party must perform on the assertion.

When to use

• A relying party consumes SAML assertions or OIDC ID tokens from an identity provider to authenticate users.
• Signature, issuer, audience, or nonce validation on the assertion may be missing or scoped wrong.
• The relying party may trust a subject, email, or attribute without binding it to the verified issuer.

Scope check

Test federation trust only against relying parties and identity providers you own or are authorized to assess, on non-production accounts. Forging or replaying assertions attempts real authentication, so use non-production identities and never authenticate as a real user. If you can't name the authorization, stop.

The loop

1. Establish the intended trust first. Name which identity provider and signing key the relying party should trust, the expected issuer and audience, and how the assertion's subject maps to a local user. This is the false-positive killer: a relying party that verifies the signature over the correct element against the expected key, checks issuer, audience, and nonce, and binds the subject to the verified issuer is correct. Name the intended trust, then test each check.