What happens when a service provider accepts unsolicited SAML responses without InResponseTo checks?

Why unsolicited SAML responses are dangerous

When a service provider accepts a SAML response without checking InResponseTo, it stops treating the assertion as a direct answer to a specific authentication request. That breaks an important anti-replay and anti-misbinding control. In practice, the provider may accept a valid-looking response that was never tied to the current browser session or login attempt.

This matters most in IdP-initiated or loosely bound flows, where the SP cannot rely on a fresh request context to confirm intent. A response that is not linked back to the original request can be delivered out of sequence, reused, or associated with the wrong user session. The result is not just weak authentication, but weak session binding.

For teams trying to understand the control failure, the core issue is trust in the message relationship, not only in the signature. A signed SAML assertion can still be unsafe to accept if the SP does not verify that it was issued in response to a legitimate request it actually generated.

What attack paths this opens up

Unsolicited response handling can enable replay, interception, and session confusion because the SP is no longer enforcing a one-request, one-response relationship. If an attacker can obtain a usable assertion or influence the browser flow, they may be able to present a response that the SP will accept even though the user did not initiate that specific transaction. That is why this issue often shows up alongside other federation weaknesses such as response forgery and assertion reuse.

The control is especially important when the login state is established by the SP after the response arrives. Without request binding, the application has a weaker basis for deciding which user identity, which browser session, and which target application the assertion is meant for. That creates a practical path to unauthorized login if other checks are also permissive.

For broader federation hardening, the same discipline applies to the rest of the trust chain as well. NHIMG’s SAML Security Guide covers the response-forgery and replay classes that sit behind this control failure, and the Identity Provider and SSO Security Guide is useful when you need to harden the federation path end to end.

How to verify and enforce the check

The first verification step is simple: confirm that the service provider can correlate each incoming response to a live, expected request identifier. If it cannot, the implementation is relying on assertion validity alone, which is not enough for safe request-response binding. The SP should reject responses that do not match an outstanding authentication request and should log those rejections for review.

Teams should also test how the SP behaves when the same assertion is replayed, delayed, or sent from a different browser context. A robust implementation will refuse responses that arrive without the expected correlation data, and it will fail closed rather than trying to “helpfully” complete the login. That behaviour is especially important where federated SSO is shared across several applications.

Where the federation design includes service-provider responsibility reviews, the question is whether the SP can prove that request-state checks are in place and consistently enforced. The CIS Control 15 Service Provider Management Guide is useful for thinking about that control as part of provider governance rather than as a one-off technical setting.

Risk and Threat Considerations

Accepting unsolicited SAML responses weakens the trust boundary around federation and increases the chance that a valid assertion is consumed in the wrong context. The practical risk is not only unauthorized login, but also brittle session handling, inconsistent identity attribution, and harder-to-detect abuse of federated trust.

Failure mechanism: The SP accepts a response without proving it was generated for a specific outstanding authentication request, so replayed or misdirected assertions can be accepted as if they belonged to the current session.

Impact: An attacker may be able to reuse assertions, confuse session state, or obtain unauthorized access if the response is accepted outside the intended request flow.

Practitioner Guidance

What to verify: Check that InResponseTo validation is actually enforced on the production path, not just documented. The safest test is to send a response that lacks a matching request identifier and confirm the SP rejects it consistently.

Decision rule: If the SP cannot bind each assertion to a live request, treat the federation flow as unsafe for high-trust access decisions until the control is fixed. Do not compensate for missing binding by relying on signature validation alone.

Practitioner takeaway: In federated login, the security question is not just “was the assertion signed?” but “was it issued for this exact request and session?”

Related resources from NHI Mgmt Group

• What breaks when a service provider accepts unsolicited SAML responses?
• What happens when SAML assertions are accepted without matching the service provider configuration?
• What happens when a service accepts Kerberos authentication without verifying the KDC?
• What happens when a managed service provider or shared platform is compromised without strong segmentation?