No 'Access-Control-Allow-Origin' header is present on the requested resource

I’m having the exact same issue with my production environment.
I’m using two different tenants for dev and production, but the app settings in Auth0 are the same in both.
Dev works, production doesn’t.
I also tried using older code that used to work with current setup and it doesn’t anymore.
So I’m risking a guess it’s not on my side. Did an update go live over the weekend or something?

There has been an update to Universal Login on the 14th according to the changelog.

auth0-js ver. 9.12.2
But as I mentioned before - the same code works on one tenant but not on another with the same settings.

Seems like it has something do with CloudFlare and Auth0’s setup with them, that’s the best guess I’ve come across.

I am having the same issues since upgrading from Chrome 87.0.4280.88 to Chrome 87.0.4280.141 today. Also have co-workers and customers reporting issues. Anything I can do in my setup to remedy, or it is on Auth0’s end?

Interesting! It doesn’t work in Chrome (also 87.0.4280.141), or Edge for me right now, but works in IE when i build with es5 support.

This will get us by for today, but waiting closely for updates.

Same issue here, since yesterday at least.

Encountered in Chrome and Edge, for some specific users on some specific environment.
It is a BIG issue right now and we have no visibility on what could have gone wrong.

We have an increasing number of users concerned by the error - as it seems to be “sticky”.
Please report all your cases to Auth0, they need to investigate at this point.

It indeed looks like auth0’s cloudflare configuration problem.
/.well-known/jwks.json request doesn’t return any CORS headers, and changing settings doesn’t reset the cache (getting the same x-auth0-requestid)

Hey there everyone!

Sorry for all the inconvenience! Let me dive into it with our engineering teams! Can you update your posts with the SDKs that you are using in your implementations?

auth0-js version “9.14.0”

1 Like

From the looks of it, “origin” header plays a role in auth0’s cloudflare configuration, so using an alias for hostname, and adding it to CORS settings in admin panel would be a temporary solution to bypass cloudflare cache. Testing it now.

This, of course, would be only relevant for teams that can rename the service URL.

UPD: confirmed that it worked

1 Like

We can confirm that the issue is (at least partially) related to CloudFare cache settings :

  1. the issue can be confirmed with a simple curl request :
    curl ‘’ -i -H ‘Accept: /’ -H ‘Origin:

  2. When the access-control-allowed-origin header is absent (CORS config invalid), x-cache-status header value is HIT

  3. When the access-control-allowed-origin header is present (CORS config valid), x-cache-status header value is MISSED or BYPASS

  4. We manage to trigger the case by simply changing our outgoing IP with a VPN and replaying the same curl request :

  • an outgoing request from Paris returns an invalid CORS config
  • an outgoing requestion from NY returns a valid CORS config,
  • etc…

We’ve tried to change our Allowed Origins config in the dashboard to see if it would invalidate the caches, but this didn’t work :frowning:

Hope this helps,

– Fairjungle team

Can you let me know what SDK you are using in your implementation?

Hello Konrad,

yes, sorry.

Client side :  "auth0-js": "9.11.3" 
Auth0-hosted Universal Login page:   <script src=""></script>

But as we said, we reproduce the issue with a simple curl command (that is outside the browser), so no SDK is involved at all to reproduce the issue.

Thanks again,

– Fairjungle team

1 Like

Thanks for providing that context!

WARNING: This is a hack. Revert when Auth0 has fixed the issue.

To everyone who ends up here with the same issue in production, here is a workaround while Auth0 team fixes the issue:

Download the current version of your jwks.json file (generally available at and store it on your domain to avoid CORS issues, or somewhere where you can easily set CORS headers (for instance S3).

Then, client-side, when instantiating WebAuth, use a private setting to tell it where to find the jwks file:

  auth0 = new WebAuth({
    domain: ...,
    clientID: ...,
    overrides: {
      __jwks_uri: "MY_OWN_JWKS_URL"

Where MY_OWN_JWKS_URL is the URL where you stored your jwks.json.

Hope this helps,

– Fairjungle team


Hi All. We are working on this issue. I will update as soon as it is resolved.


Thanks for the headsup Saltuk!

The incident is published. You may follow up on the status from this link.

1 Like

Thanks so much for the workaround! I’ve implemented it and it is now working.

Hopefully it doesn’t take too much to be fixed, so we can roll it back.

1 Like

We’ll let you know as soon as the official fix is there! Sorry for the inconvenience!

I see this incident is being monitored - just noting I’m still seeing the behavior.