Missing InResponseTo Field in SAML Response During SP-Initiated Flow When Using a Custom Login Page With Okta

When using a custom login page for an application, Okta does not preserve the SAML request parameters, which omits the InResponseTo field from the SAML response. Using the default Okta login page or modifying the Service Provider (SP) authentication requirements to accept authentication without the InResponseTo field resolves this issue. In an SP-initiated Single Sign-On (SSO) flow, Okta provides a SAML response featuring an InResponseTo field containing the ID of the SP SAML request for validation. The absence of the InResponseTo field in the SAML response causes the SP authentication to fail.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Service Provider (SP)
• SP-initiated flow
• Single Sign-On (SSO)
• Custom Application Login Page
• Custom Login Page With the Okta Sign-in Widget Embedded

When employing a custom login page for an application, Okta preserves only the application context, such as the application URL, and not the entire SAML request. This behavior also occurs for a custom login page with the Okta sign-in widget embedded. Consequently, Okta omits the InResponseTo field in the SAML response, which causes the SP authentication to fail.

How is the missing InResponseTo field resolved?

The features of a custom login page do not function correctly if the SP requires the InResponseTo field in the generated SAML assertion. Restore successful authentication:

• Using the default Okta login page instead of a custom login page.
• Modifying the SP authentication requirements to accept authentication without the InResponseTo field.