SAML assertion failed" recipient mismatch on SSO login
Fixes SAML recipient-mismatch assertion failures by comparing the assertion's Recipient and Audience to the service provider's configured entity ID and ACS URL. Use when SSO login fails on recipient or audience validation. Not for signature or clock-skew failures.
TL;DR
The SAML response's Recipient or Audience does not match what the service provider expects. Capture the assertion, compare those fields to the SP's configured entity ID and ACS URL, and fix the mismatch on whichever side is wrong.
"SAML assertion failed" recipient mismatch on SSO loginUse this when
- SSO login fails with a recipient or audience mismatch message.
- The failure started after a URL, domain, or certificate change.
- The IdP login succeeds but the SP rejects the response.
Not for this skill when
- The error is about the signature. That is a certificate problem.
- The error mentions time conditions. That is clock skew.
- The user never reaches the IdP. That is a different failure entirely.
Steps
- Capture the SAML response using browser devtools or a SAML tracer. Verify: you have the raw assertion.
- Read the Recipient and Audience values from the assertion. Verify: you have the exact strings, including trailing slashes and scheme.
- Compare them to the SP's configured entity ID and ACS URL. Verify: you found the character-level difference.
- Fix the mismatch in the IdP app config or the SP metadata, whichever side is wrong. Verify: both sides now agree exactly.
- Re-run the login. Verify: the assertion validates and the session starts.
Variant phrasings
SAML recipient invalid
The short phrasing.
audience mismatch SSO
The field-first search.
"SAML response failed validation"
The generic message.
Compatibility: Any SAML 2.0 IdP and SP combination. The field names are standard.
Why it happens
The SP rejects assertions not addressed to it; even one character of URL difference fails the check. Trailing slashes, http versus https, and load-balancer rewrites are the classic culprits.
Edge cases / pitfalls
- Load balancers rewriting the ACS URL between the IdP and the SP.
- Multiple ACS URLs configured, with the IdP picking one the SP does not expect.
- Some SPs report clock skew as recipient errors; check time conditions if the URLs match.
- Metadata cached on either side after a URL change; force a metadata refresh.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_Qz837fnssdP2jnBWmq1CAQ