I have been implementing SAML 2.0 and testing different IDP providers including OKTA and RedHat, Azure, Keycloak.

There's a key difference I noticed between other SAML 2.0 auth providers and Okta that Okta doesn't respect the AssertionConsumerServiceURL value from SAML AuthNRequest after authentication when sending response back to SP (Service Provider)

Here's a representation,

following is an AuthN request generated by SP,

<?xml version="1.0" encoding="UTF-8"?>

<saml2p:AuthnRequest AssertionConsumerServiceURL="http://localhost:8080/core-demo/login?idpId=OKTA-demo&amp;host=localhost%3A8080" Destination="https://dev-<masked>.okta.com/app/dev-<masked>_coredemo_2/<masked>/sso/saml" ID="_3eabaae6d0c7543c625cc2083133be5a" IsPassive="false" IssueInstant="2022-08-31T10:46:27.514Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">

<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">core-demo</saml2:Issuer>

<saml2p:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />

</saml2p:AuthnRequest>

Notice the value of AssertionConsumerServiceURL is "http://localhost:8080/core-demo/login?idpId=OKTA-demo&amp;host=localhost%3A8080" containing 2 extra parameters idpId and host.

After authentication, when Okta goes back to SP, it goes without these extra parameters that SP needs. Generally SAML auth provider should send SAML Response back to SP using AssertionConsumerServiceURL.

Workaround

We can set Single Sign On URL with extra parameters in the URL like "http://localhost:8080/core-demo/login?idpId=OKTA-demo&host=localhost:8080"

So far doing same workaround in Recipient URL or Destination URL doesn't do the trick.