Safari CORS problem

Questions
#1

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.

Wade.

#2

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.

#3

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.)

#4

Hi @Wade,

Has the request to /oauth2/v1/userinfo endpoint succeed in Safari’s network logs ? What errors do you see in the console ?

#5

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.

Summary
URL: https://ext-expediagroup.okta.com/oauth2/v1/userinfo
Status: 200
Source: Network
Initiator:
okta-auth-js.umd.js:373:18963

Request
Accept: application/json
Content-Type: application/json
Authorization: Bearer [elided for security]
Origin: https://localhost:8443
Referer: https://localhost:8443/auth/callback/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
x-okta-user-agent-extended: okta-auth-js/4.5.0

Response 
Set-Cookie: sid=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/ 
Set-Cookie: JSESSIONID=689B9E8104EA32AD7F8912D09B55417B; Path=/; Secure; HttpOnly 
Cache-Control: no-cache, no-store 
Access-Control-Allow-Origin: https://localhost:8443 
Pragma: no-cache 
Content-Security-Policy-Report-Only: default-src 'self' *.oktacdn.com ext-expediagroup.okta.com; connect-src 'self' *.oktacdn.com *.mixpanel.com *.mapbox.com app.pendo.io data.pendo.io pendo-static-5634101834153984.storage.googleapis.com ext-expediagroup.okta.com ext-expediagroup-admin.okta.com ext-expediagroup.kerberos.okta.com https://oinmanager.okta.com data:; script-src 'unsafe-inline' 'unsafe-eval' 'self' *.oktacdn.com; style-src 'unsafe-inline' 'self' *.oktacdn.com app.pendo.io cdn.pendo.io pendo-static-5634101834153984.storage.googleapis.com; frame-src 'self' login.okta.com ext-expediagroup.okta.com ext-expediagroup-admin.okta.com api-f4ecbba1.duosecurity.com; img-src 'self' *.oktacdn.com ext-expediagroup.okta.com *.tiles.mapbox.com *.mapbox.com app.pendo.io data.pendo.io cdn.pendo.io pendo-static-5634101834153984.storage.googleapis.com data: blob:; font-src data: 'self' *.oktacdn.com fonts.gstatic.com; report-uri https://okta.report-uri.com/r/d/csp/reportOnly; report-to csp-report 
Access-Control-Allow-Headers: Content-Type 
X-XSS-Protection: 0 
Date: Mon, 04 Jan 2021 04:35:38 GMT 
Vary: Origin 
Expires: 0 
Content-Type: application/json;charset=UTF-8 
Access-Control-Allow-Credentials: true 
X-Content-Type-Options: nosniff 
p3p: CP="HONK" 
Server: nginx 
x-robots-tag: none 
Strict-Transport-Security: max-age=315360000; includeSubDomains 
x-rate-limit-remaining: 5997 
report-to: {"group":"csp-report","max_age":31536000,"endpoints":[{"url":"https://okta.report-uri.com/r/d/csp/reportOnly"}],"include_subdomains":true} 
public-key-pins-report-only: pin-sha256="r5EfzZxQVvQpKo3AgYRaT7X2bDO/kj3ACwmxfdT2zt8="; pin-sha256="MaqlcUgk2mvY/RFSGeSwBRkI+rZ6/dxe/DuQfBT/vnQ="; pin-sha256="72G5IEvDEWn+EThf3qjR7/bQSWaS2ZSLqolhnO6iyJI="; pin-sha256="rrV6CLCCvqnk89gWibYT0JO6fNQ8cCit7GGoiVTjCOg="; max-age=60; report-uri="https://okta.report-uri.com/r/default/hpkp/reportOnly" 
x-rate-limit-reset: 1609734997 
x-rate-limit-limit: 6000 
x-okta-request-id: X-KbGlKQDDc9UCkwMPkSYwAACjY 
expect-ct: report-uri="https://oktaexpectct.report-uri.com/r/t/ct/reportOnly", max-age=0
#6

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.

#7

Thanks for the details, @Wade.

Could you make sure this is not a possible network issue ? I could see from our backend logs that this particular /userinfo call has succeeded.

If you still face issues, please reach out to developers@okta.com with the details and har file fo more help.

#8

We’ve solved the problem.

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.

#9

@Wade Glad to know the issue is resolved. The case is closed.

#10