RedirectURI causes error in Angular Deployment

[heather.frazier]

Has anyone else had issues using the RedirectURI in an Angular deployed environment with IIS? I was able to create an application that uses the OKTAAuth.HandleLoginRedirect which works great in our development environment. However, it does not work in our deployed envrionment and results in a 400: BAD REQUEST error.

Using the http://localhost:4200/login/callback works great as the RedirectURI for the dev enviroment. The sign in widget is displayed and after logging in the user is redirected back to the correct page.
Those values have been changed in the OKTA app to reflect our production deployment values (e.g. http://myserver.com/myserver/login/callback) but unfortunately in the deployed environment when we hit the “Login” button (which should direct us to the OKTA sign in widget), we get a 400: Bad Request error. All other routes that do not require OKTA sign in work in the deployed environment.

[erik]

Hello,
Could you provide the request URL/parameters causing the 400 from the address bar or dev console network tab. I also notice that the callback URL is http vs https. When you create the OktaAuth instance are you passing disableHttpsCheck: true as one of the parameters?

[heather.frazier]

Hi Erik, I am not passing the passing disableHttpsCheck: true parameter through. My OKTA instance is https; although my testapp is not (thus the http in the redirect configuration).

Here is the URI being sent to OKTA for the login redirect… in development mode this brings up the OKTA login screen and then redirects back to my app correctly once credentials have been verified. However, once the app is deployed the login screen never comes up. (It is not making it that far.) I noticed others saying that once they log in they are not being redirected correctly, but for me I am not even getting the login screen to come up once deployed.

https://dev-58568392.okta.com/oauth2/default/v1/authorize?client_id=0oa4l9bj0ZI5hNLjP5d6&code_challenge=Al7OBpW7AAI1XGSZUD7JW5HwMe9Ri8kD_5lmwKOis8E&code_challenge_method=S256&nonce=SxvgLDlTo3AbWxrRj6LNbYI1irNWpbENC9jx73OqlEcBLMz8Z9AWihc4cfd0c5KF&redirect_uri=http%3A%2F%2Flocalhost%2Flogin%2Fcallback&response_type=code&state=oHgfYyzpN6acGU2IjqsCyhw9nW8GXqgIwd5Gq0ll6pPy3WALbf05AtAv187taHfx&scope=openid%20email%20profile

[erik]

If I click on that URL I get
The 'redirect_uri' parameter must be a Login redirect URI in the client app settings
It looks like the redirect URI is set to http://localhost/login/callback. Should this be set to the URL the application is being downloaded from when it is deployed, https://myserver.com/myserver/login/callback

The comment about others are able to login but have issues with redirecting afterwards. I am not sure what version of the Okta Angular SDK is being used, but if the application is being deployed to https://myserver.com/myserver, as opposed to the base https://myserver.com, the issue could be this bug which has been resolved as of 3.0.1

[heather.frazier]

You are correct, that is the error I am getting. However, the redirect URI is not set to the localhost (it was during development, but I had to change that during deployment). Currently it is set to http://IPADDRESS/myserver/login/callback (see description)

[erik]

I do still see http://localhost/login/callback in the latest logs.

Even though the application is configured for a different URL in Okta I am guessing that the Angular application still has localhost somewhere in the configuration for redirectUri.

Can you check the redirectUri Okta config setting in the Angular app.

[heather.frazier]

I have been going back and forth trying various things in order to get it to work, which might be what you are seeing? This is what the configuration in the code is currently. I have tried several different iterations to see whether I could get it to work.

I am using the following to build the application…

ng build --prod --base-href /PSOWebComm/

And when I deploy via IIS, the name of the deployment is PSOWebComm…

I have tried to hardcode the redirectUri to the following with no success:

‘localhost/PSOWebComm/login/callback’

‘IPADDRESS/PSOWebComm/login/callback’

[erik]

Just to verify when you access the application after it is deployed you are using http://ip_addr/PSOWebComm to accces the app and not the localhost version? Which could cause this to happen.

I recommend opening a support case with support. We would like to be able to get a .har file and go over more of the configuration since SPA application deployments add extra complexity compared to traditional web apps.

[heather.frazier]

Correct. http://IPADDRESS/PSOWebComm

Thank you so much for your help. I will contact support to open a ticket as I realize this is not just a straightforward issue. I will also do some further investigation on the bug and it’s subsequent workaround that you referenced previously.

Thanks again!!

[heather.frazier]

Hi Erik! I opened a case in Support as you suggested, but have not been able to get anywhere as everything they have suggested does not fix the situation. I have created a simple angular app that just does a login and logout based on the documentation that I was given. The result is the same, with a small caveat. I also added the ability to Logout once I have logged in and I am having a problem with that in Development as well. Unfortunately OKTA Support says they can not help me with anything that has anything to do with code. Is this something that you might be able to help with??

Here are the details of my problem(s):

[heather.frazier]

Please disregard the “Logout” error. I was able to resolve that by only including the machinename/port for this in development which works. The “Login” issue during deployment still holds true.

[erik]

Hi Heather,
I recommend to try to change the login redirect uri within Okta to https://psodemo/PSOWebComm/login/callback

Note the change is the hostname to all lowercase. Assuming your code is still using window.location.origin I am guessing the hostname will be all lowercase. Okta will do a direct string comparison.

If you still see the same issue verify that in the dev console network tab of the browser that when the /authorize call happens that the redirect uri sent to Okta exactly matches what is set in the Okta application.

One last thought, if you have more then one application in Okta, verify that when you change between the two the correct client_id in the source code is updated.

Hopefully one of those will work!