auditing-saml-and-oidc-federation-trustlisted

# 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 Tes