IdP Discovery redirect URI not working as documented

[rolandharrison]

ℹ️ 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

• bug report
• feature request

Background info

I'm trying to enable idp Discovery on the sign in widget. As per the documentation a URI is provided to the redirectToIdp method returned in the success method for the sign in widget render method. See IdP Discovery

I have an IWA setup, so I am redirected via that flow from the sign in widget.

Expected behavior

The URI I provide to redirectToIdp should be added as a query parameter with the key "fromURI".

What went wrong?

The URI is not added as a query parameter. The login_hint is added only.

If I add the URI to the configuration for the Okta Sign In:

idpDiscovery: { requestContext: '/home/oidc_client/abcdefg/hijk1234' },

Then the fromURI is added as a query parameter with the contents of requestContext in the redirect.

Steps to reproduce

1. Follow the suggested configuration steps from the README - IdP Discovery

Your environment

• Okta Sign-In Widget Version: 2.20.1
• Browser: Chrome 75.0.3770.100 (Official Build) (64-bit)
• OS: Windows 10
• Language: English

[restfulhead]

I've noticed the same. Using requestContext works, as mentioned in this article https://support.okta.com/help/s/article/Relay-state-lost-when-using-IDP-Discovery-in-Sign-In-widget

Yet this setting was removed, see #649 and #670. The pull requests don't mention why it was removed or what is the alternative. If the alternative is to set this URL in redirectToIdp, then I can second, this is currently not working.

@rolandharrison I have an additional issue. I'm unsure how to retrieve the access and id token after the redirect. Were you successful in retrieving them?

[rolandharrison]

I did manage to get the tokens. I will provide a little more information in case it helps anyone else.

I first set up the SPA application with "Login initiated by" set to "Either Okta or App". The "Login Flow" to "Redirect to app to initiate login (OIDC Compliant)". This gave me the embed link for which I could extract the value for the sign in widget configuration.

In the widget, I enabled the idpDiscovery feature and set the idpDiscovery.requestContext just as above. In the onSuccess callback of the sign in widget render method, I added the suggested code to start the redirect to the IDP:

if (res.status === 'IDP_DISCOVERY') { res.idpDiscovery.redirectToIdp() }

Then the change that will probably help you out, Patrick, was to check for a session once I had come back to the application after a successful authentication at the IDP. After you construct the new OktaSignIn, you can call session.get() and pass it a callback function. If there is a session, I used Okta auth library to trigger a redirect for the access and user info tokens. If not, then render the sign in widget.

This sign in widget was hosted in a React project. So by using the withAuth wrapper, my props provided this method to call: props.auth.redirect() start the flow for the tokens.

[restfulhead]

Roland, thank you for the additional information, much appreciated! So with IdP Discovery I have to do a little more manual work. Basically I need to get the session (okta/okta-auth-js#session) and then get the token (okta-auth-js#token) for example by doing token.getWithoutPrompt() passing in the session id.

[vejandla]

@rolandharrison or @restfulhead

Was it working for you? for me after I got redirected from my internal Sso signin page, the tokens are not getting passed. Is there any working example that we can find at documentaion?

[brvaland]

@restfulhead or @rolandharrison - is it working for you ? I tried as suggested but getting similar issue as @vejandla as redirected to internal sso signin page and not getting id and access token.

[rolandharrison]

@brvaland I'm not sure how it would be configured in the current form of the widget. @restfulhead had what looked like a better flow.

We have since dropped the sign in widget from our codebase due to the changes in Safari around third party cookies being blocked by default.

[restfulhead]

@brvaland The workaround was successful for me way back then. However, it involves getting the session (okta-auth-js#session) and that requires third party cookies. As @rolandharrison said, less and less browsers support them by default. That's why we switched to the hosted login page and no longer use the widget either. So, I don't know if the this still works.

[brvaland]

@restfulhead - Thanks for your feedback i was thinking to use custom domain to fix the cookie issue - https://support.okta.com/help/s/article/FAQ-How-Blocking-Third-Party-Cookies-Can-Potentially-Impact-Your-Okta-Environment. Is it possible for you share a workaround as gist file ?