Okta Authenticating but not Getting Code When Deployed

[steveevrard]

Hello!

I recently integrated Okta into an application I am building and I have been able to run it locally and had no problems. However, I recently tried deploying the app to OpenShift and now the sign in is timing out after the /authn call even though the calls status is 200. The user appears to be getting authenticated but then the redirects to get a code and token are not happening. I cannot seem to find any reason why it would succeed locally still but not when deployed. I have added the redirect uri’s of my deployed url to the login settings and to the API > Security section as well

Above is the network calls made when deployed, you can see it stops after the /authn. Below is when the sign in is run locally and makes the successful call that gets all 3 calls (/authn > /authorize?client_id > /token) and then properly redirects to the apps home page.

Thanks in advance to anybody that is able to help!

[Fuzzard]

are there any hints about the problem encountered here in the browser console?

[steveevrard]

Nope nothing comes up in the console. No errors, warnings, etc.

[gsvivek]

Check the response body of the authn call in the network tab to see what it sent. Also re-verify your Okta app config for the login redirect and the initiate login URI are updated correctly. If you are using Okta SDK, re-check the config for Okta issuer and org URL. Is your OpenShift on https? Is the cert valid? Have you configured http at one place and https in another?

[erik]

One of the ways I am able to reproduce this is if I have multiple alias for the host. In my Okta application I setup the callback URI as http://localhost:3001/callback. In my widget client configuration I use the same value for the redirect URI. Then when I access my application I don’t use localhost, I use http://myhost.test.com which I have setup in my hosts file as an alias to localhost. When I attempt to login, I enter my credentials, /authn returns success,

{
  "expiresAt": "2021-03-06T00:17:55.000Z",
  "status": "SUCCESS",
  "sessionToken": "20111x3X3zOy3fYuDNVb9IpGI70xvcu3Krb7IYHJXuSCxExuRm6JOPA",
  "_embedded": {
    "user": {
...

but the widget stays on the screen clocking, no call to /token happens, no errors in the console log. I suspect something similar could be happening here.

[steveevrard]

Hey Erik! Thank you so much for following up on this. Correct this is the exact issue that is happening to our app when deployed. Do you have any advice on possible solutions/ways to go about further troubleshooting?

[tyty]

Just to be clear, the entire login flow works correctly when running on localhost without an alias?

[steveevrard]

I believe so, by aliases you mean the login/logout redirects? This is how it is currently setup.

[erik]

The issue could be that you are using http for a host other than localhost. I assume you are using pkce?

How this behaves can depend on browser/version/configuration. For example if I configure the widget for pkce with localhost as the redirect URL. The I access the app using an alias for localhost, non SSL

In the latest chrome it will just clock on authn. If I open dev tools before trying to login chrome starts my debugger and gives a message AuthSdkError: PKCE requires a modern browser with encryption support running. This may not happen in all Chrome versions

In the latest Edge it will just clock after authn whether dev tools is open or not. Could be a configuration issue in the browser.

Safari will do the authn call and then proceed to /authorize. This may or may not fail. If I have the redirectUri set as localhost, but access with an alias, and configured post_message (default for SPA), the post will fail.

If you can provide the browser, how the Okta Widget is configured (pkce/implicit/hybrid, response_mode, full redirect_uri) and then how the application is being accessed, same URL as the redirect URL or an alias,

It maybe easier to open a support ticket with us so you can send us more information on your tenant and we could go further into the configurations.

[steveevrard]

Thanks Erik, that could be an issue then going between http and https. Above is the current config.js we are using and the browser we are running on is Chrome 88. However I just tried using safari to run the app and it is working as expected. So it appears to be an issue when running just in Chrome. I currently have a ticket open with as well that I communicating with Ty on I believe