 Hey, folks! We are answering frequently asked questions from the Okta customer identity cloud community, and today we are going to discuss how to resolve the error the in-response-to-attribute does not match the ID in the auth-n request during a SAML login attempt. Let's get started. This error most commonly occurs if you are not using the same domain for both the authorized request that initiates the login flow and the ACS URL configured on the identity provider side that sends the SAML response to Auth0. If you are beginning the login flow by using your tenant's custom domain in the authorized request to Auth0, you will need to make sure you are also using your custom domain in the login callback request. If your domain is for the authorized request and ACS URL switch between the custom domain and the canonical domain or vice versa, you will see this error. Here we see a hard file of the network traffic captured when we got this error. At the top, we have our authorized request, and we see that it is using our tenant's custom domain. Scrolling down, we'll see a post request to the login callback endpoint, but we'll see that it's using our tenant's canonical domain. To fix this, we will need to go to our identity provider settings. In this case, we are using Okta as the identity provider, and we will update our ACS URL or as it's called here, our single sign-on URL to now use our custom domain. Having these domains now match will resolve this error for you. If the domain values are matching and you're still seeing this error, there are a couple of other less common reasons for this error. If your browser is blocking cookies, it may be preventing the Auth0 cookie from being sent in the post request with the SAML response. It's also possible that the in-response to attribute in the SAML response does not actually match the ID value in the SAML request. You can check this by looking at the network traffic and finding the SAML request and the request to the identity providers sign in URL. We can copy this value and take it to SAMLTool.io where we can decode it. Here at the top, we will find the ID value. Back in our HAR file, we can go to our post request to our login callback, and in the post data, we will see the SAML response here. We can copy this value and also take it to SAMLTool.io and paste it here to decode it. Here we can confirm if the in-response to value is both there and matches the ID that was in our SAML request. If this in-response to attribute is missing or incorrect, work with your identity provider to make sure that it is not mistakenly sending an IDP-initiated login request and that the correct value is being sent. Today, we looked at how to resolve the error. The in-response to attribute does not match the ID in the often request during a SAML login attempt. If you found this video helpful, please like and subscribe to us on YouTube and join us for more content on community.auth0.com.