I have created two different identity providers one saml2 based and another one OIDC, pointing to azure active directory, and have written routing rules accordingly which is working as expected.
However, I am unable to get any token information when redirected to localhost.
When I don’t give idpDiscover.requestContext in Okta sign-in widget configuration, I am able to login to OKTA home. So, it seems Okta is getting session information from Azure AD, however it’s unable to redirect to localhost. And why callback URL given in the application is not being honoured in case of IDP discovery?
If you are using the org-level sign-in widget (eg. redirecting to your Okta tenant for authentication), the widget should automatically pick up the details and provide the context automatically.
If you are using the sign-in widget hosted on your end, for the moment you will need to create a custom logic for covering this use-case.
Thanks for the response. Any references/ideas on how to do that?
In case of okta-hosted-login, after getting the SAML response from IDP, a POST API call happens to ACS url:
https://[okta-host]/sso/saml2/[idp-id]
With SAMLResponse and RelayState e.g.
/oauth2/v1/authorize/redirect?okta_key=[okta-key]
This relay state is same as the one sent while making call to IDP.
Now next (authorize) call happens to the Okta host using this relay state, which after redirect gives authorization-code and state. Afterwards it’s same as authorization code flow.
I was thinking in custom-login after redirect happens to my host, I can call this authorize endpoint (mentioned above) in my custom callback component to get the authorization code.
However, to make that work I’ll need okta-key which is dynamically generated with every request?
I have the exact same problem. And I still cannot handle it. The session cookies on both SP & IDP isn’t created, although The system logs of Okta showing the user is authenticated successfully. Any update on this please ?