Auth0 SAML Error "The InResponseTo attribute does not match the id in the AuthNRequest"

SAML login attempts return the error below in an HTTP Archive (HAR) file/network trace.

The InResponseTo attribute does not match the id in the AuthNRequest

This will either result in a failed login or, depending on the SAML IdP, can result in confusing behavior. An Okta SAML IdP connection was seen defaulting to IdP-initiated login due to this, which was undesired behavior.

Obtain a network HAR file of a login attempt and look for this error:

https://DOMAIN/callback?error=access_denied&error_description=The%20InResponseTo%20attribute%20does%20not%20match%20the%20id%20in%20the%20AuthNRequest&state=<value>

• Auth0
• Security Assertion Markup Language (SAML) Enterprise Connections
• HTTP Archive (HAR)
• Custom Domains
• Service Provider (SP) initiated SAML login flows

This error occurs when the InResponseTo attribute in the SAML response is not recognized by the Auth0 tenant. This error could be caused by:

• Blocked cookies.
• Mismatched IDs from the most recent SAML request.
• Inconsistent use of domains.
• AssertionConsumerServiceURL attribute is missing in the SAML AuthnRequest sent to the Identity Provider (IdP). 

If the tenant uses a custom domain, there could be a mismatch if the login flow begins on the custom domain and finishes on the canonical domain.

Without the AssertionConsumerServiceURL attribute, the IdP defaulted to the ACS URL configured in its settings (the custom domain). Since the application initiated the /authorize request against the canonical domain, Auth0 stored the session state under that domain. When the SAML Response arrives at the custom domain, Auth0 cannot match the InResponseTo attribute with the original request, causing the validation to fail.

To fix this problem:

•  Use the same domain throughout the login flow. Change either the domain in the initial /authorize request or the ACS URL with the identity provider so they match.  
• Make sure the SAML Request template does not use a hard-coded string value for the ID in the SAML request, instead of the ID="@@ID@@" that generates an ID value for each login request. 
• Ensure the IdP administrator adds the canonical ACS URL (https://[tenant].auth0.com/login/callback?connection=[connection-name]) as an allowed Reply URL in their SAML configuration, alongside any existing custom domain URLs.
• Update the SAML connection's Request Template in the Auth0 Dashboard to explicitly include the AssertionConsumerServiceURL attribute. Navigate to Authentication > Enterprise > SAML > [Connection Name] > Settings and update the Request Template to:
  

  <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
      AssertionConsumerServiceURL="@@AssertionConsumerServiceURL@@"
      Destination="@@Destination@@"
      ID="@@ID@@"
      IssueInstant="@@IssueInstant@@"
      ProtocolBinding="@@ProtocolBinding@@" Version="2.0">
      <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">@@Issuer@@</saml:Issuer>
  </samlp:AuthnRequest>