My team and I are in the process of some long-delayed upgrades to a web application we’ve inherited. One of those upgrades is to the Okta Auth API. It’s a Typescript app on top of an enterprise library built on React and Express JS. We’re using Okta’s AuthJS library to talk to Okta.
The upgrade is mostly complete. Unfortunately, we now have a CORS problem in Safari that is breaking the login process.
Our login process has several steps between accepting login credentials before creating a local logged in session. After passing a correct MFA response to Okta, it proceeds to create the local session. The first step is to find the user information, which is a call to authJS’s getUser() call. The path it is calling is /oauth2/v1/userinfo on our Okta tenancy. But this fails in Safari (and only Safari) with a CORS error.
And that’s where I’m stuck. Safari is not telling me enough about what’s wrong to know what to fix.
If I send the exact same request that Safari is listing in its debugger from Postman, then I get a correct response. If I edit the request to be an OPTIONS request, again, I get a valid and correct response. And one that matches what Safari reports. But it still tells the Javascript that it failed without any hint of as to why.
I’ve just realized that Safari is not actually reporting a CORS error - but it’s not giving the response to the JavaScript, so the Okta AuthJS library is thus returning an “ApiError” object with a Network Error inside. Yet the debugger says the call returned a 200. I’m confused.
(Note that I’ve not used Safari before and its debugging tools are not behaving in ways I am used to.)
Safari does not report an error in the console. I cannot tell if the call to /oauth2/v1/userinfo has succeeded or not as Safari is reporting inconsistent information.
In the Network tab, it shows the request line in red with no return code
the Request Headers and Response Headers are present, but there is no Response
the Summary block shows Status: 200 for me, but not for another dev
Pasted below is from Safari except I’ve removed the Bearer token. Making this exact call works outside of Safari.
I should add that this works just fine in Safari with an older version of our application in all the same domain names. However, that app is using a significantly older version of the Okta libraries.
The issue was we were asking the Okta library to do just a little more than we needed: retrieve the auth callback tokens and then do a browser redirect via Okta (we only needed the former). This came about because the library upgrade was a big step and several calls did not have updated versions, so we used the wrong one without realizing it. Changing the code path to only do the token retrieval and then relying on our own code to do any further redirects avoids the Safari CORS problem.