What is the difference between Destination and Recipient in a SAML response?

How Destination and Recipient differ in a SAML response

Destination and Recipient serve different checks in the response path. Destination tells the service provider where the SAML response envelope is being sent. Recipient tells the assertion where it is allowed to be consumed. In practice, both often resolve to the same ACS endpoint, but they validate different parts of the message and can fail independently.

The distinction matters because SAML processing is not just about “did the browser arrive at the right place.” The identity provider’s response target and the assertion’s allowed consumer are separate security and routing assertions. That separation helps prevent response replay, misdelivery, and assertions being accepted by an endpoint that was not intended to process them.

Why both values are usually the ACS URL, but not the same check

In standard web SSO, the ACS URL is the normal common value because the service provider both receives the SAML response and consumes the assertion there. Even then, the fields are checked differently, and implementations should treat them as separate validation points rather than a single string comparison. The exact behavior is defined by the SAML profile and the product’s own parser.

When the two values diverge, the key question is whether the product supports the scenario at all. Some setups use different endpoints for different flows, but if the metadata and configuration do not line up exactly, login failures are expected. That is why a seemingly small mismatch can break an otherwise correct federation transaction.

For the specification side of the flow, the SAML profile documentation and the vendor’s own federation guidance remain the authoritative references. If you are mapping the response to a different endpoint model, verify the metadata, the ACS binding, and the endpoint that the service provider has published before changing any trust assumptions.

What breaks when Destination and Recipient do not match

A mismatch usually means the response is rejected before the user reaches the application session. That can happen when the IdP posts to one URL but the assertion expects another, when metadata was copied incorrectly, or when a proxy, load balancer, or environment-specific hostname changes the endpoint identity.

These failures are often operational, but they can also indicate a security control doing its job. If the assertion can be accepted at an unexpected endpoint, the deployment may be vulnerable to response confusion, misrouted assertions, or acceptance of a message outside the intended trust boundary. If the values differ unexpectedly, the failure should be treated as a configuration issue first and a trust issue second.

NHIMG’s SAML Security Guide covers the broader validation failures that can make a SAML flow unsafe, including response forgery, signature validation problems, replay, and assertion handling mistakes.

Risk and Threat Considerations

When Destination and Recipient are loose, inconsistent, or accepted too broadly, the risk is not just failed sign-in. The more serious issue is accepting a SAML response or assertion at an endpoint that was not the one originally intended by the federation trust relationship. That can widen the blast radius of a misconfiguration and create room for replay or response substitution mistakes.

Failure mechanism: A deployment accepts an assertion at the wrong endpoint, or treats the response envelope and assertion consumer as interchangeable, which can let a malformed or misrouted federation message pass validation in an unintended path.

Impact: The result can be broken login flows, inconsistent trust enforcement across environments, and in the worst case an authentication acceptance condition that is broader than the service provider actually intended.

Practitioner Guidance

What to verify: Confirm that the IdP metadata, SP metadata, and live ACS URL all agree exactly on scheme, host, path, and environment. If a reverse proxy, CDN, or vanity domain is involved, verify the externally visible ACS endpoint rather than assuming the back-end URL is the one being checked.

Decision rule: If only one field fails, do not “fix” it by loosening validation. Correct the published endpoint or metadata first, then re-test the full SAML transaction so the response target and assertion consumer remain aligned.

Practitioner takeaway: Treat Destination as the response routing check and Recipient as the assertion consumption check, because collapsing them into one mental model is a common cause of broken federation and weaker trust validation.

Related resources from NHI Mgmt Group

• What is the difference between SAML request signing and response encryption?
• Who should own response when sensitive data is sent to the wrong recipient?
• Who is accountable when a SAML integration accepts the wrong issuer, audience, or destination?
• What are the signs that a SAML authentication flow is failing open instead of validating the response properly?