Open rcollette opened 4 years ago
@rcollette did you ever find a solution to this? We're currently experiencing the same issue, and I'm trying to see how an okta_key
can be generated to enable the redirection to work.
@jayhoogle - I did not. I had to abandon the widget. I had a support ticket that went round and round between people and never got resolved. It was a bad customer experience.
@rcollette Just want to check if you have added localhost
to the trust origin?
Yes I did.
@rcollette Thanks for the report.
Internal investigation ref: OKTA-354752
:information_source: If you have a question, please post it on the Okta Developer Forum instead. Issues in this repository are reserved for bug reports and feature requests.
I'm submitting a
Background info
I am using the idpDiscovery feature, which winds up routing to Microsoft as a SAML Identity Provider (IDP).
The post back to Okta Service Provider (SP) includes a RelayState that is the fully qualified URL back to the application where the widget is being used (ex. http://localhost:4041/sign-in), having been set from window.location.href.
Expected behavior
After the post to Okta (SP) the client should be redirected back to my application, including the proper host name.
What went wrong?
After the POST to Okta (SP), Okta redirects to the current host (SP) with the path of the URL provided in the RelayState parameter. The protocol and host portion of the relayState is ignored.
Steps to reproduce
As a developer, I don't have the authority to setup a full flow, including a Microsoft IDP, that can demonstrate this, but I will provide as much relevant information as I can.
Widget configuration
The client calls webfinger
With response
I'm going to skip the initiation of the SAML flow at this point but the post back from Microsoft idp looks like:
Note the RelayState at the very end of the raw data in that curl. It is the requestContext that was originally set using
window.location.href
, so it is "correct".However, the response to that POST is a 302 redirect to the SP, https://host/sign-in?fromLogin=true, rather than to localhost.
I have referenced the following two sources regarding deep links: https://developer.okta.com/docs/reference/api/idps/#redirect-with-saml-deep-links https://devforum.okta.com/t/how-do-i-find-app-location/2630/4
However, as far as I am aware, as a client application, I am not able to control the creation of the POST from the Idp to the SP to include app-location and app-id in the POST URL back to the SP.
We do have a hosted login page that does not use the widget, it first makes an /authorize call that contains the redirect uri (again a full url to a client that includes protocol and domain) and when going to Microsoft, the relay state is
I imagine that the callback to /oauth2/authorize/redirect with okta_key is in some way enabling the redirect to the client properly.
Your environment