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

Help
1

Hi community,
I have an issue that suddenly I get a CORS error when requesting “/.well-known/jwks.json”.
Access to fetch at 'https://<acc>.auth0.com/.well-known/jwks.json' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

I have not changed anything. Any idea why this happens suddenly?
Entries for CORS in auth0 is: http://localhost:3000, http://localhost:3000/, http://localhost:3000/callback

  • SDK: auth0-js
  • Version: 9.14.2
5 Likes
2

Hi,
I have the same issue as of today.
I noticed that if I use https it is not happening, but it is not ideal as it more convenient to use http for local development.
You can try it as a workaround for the meantime though…

3

Having exactly the same issue as of today. And it’s stopping local development since we’re heavily integrated with Auth0.

Published/hosted versions seem to still work fine, they are running on the same URL however, not API/Front end running on different URLs for local development, probably thus the CORS error?

4

One of our users is experiencing the same issue today, on Friday it was working fine. Can the issue be affecting only users from specific locations?
The user affected is from Jordan, other users from Spain, Ghana and India are logging in fine.

This is an Angular SPA using auth0-js v9.13.4

5

Now I get a report from another user from India with the same issue…

6

Also experiencing this. Quite a big issue.

7

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?

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

EDIT 2:
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.

8

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

9

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?

10

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.

11

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.

12

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)

14

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?

15

auth0-js version “9.14.0”

1 Like
16

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
17

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 ‘https://xxxx.eu.auth0.com/.well-known/jwks.json’ -i -H ‘Accept: /’ -H ‘Origin: https://xxxx.com’

  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

18

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

19

Hello Konrad,

yes, sorry.

Client side :  "auth0-js": "9.11.3" 
Auth0-hosted Universal Login page:   <script src="https://cdn.auth0.com/js/lock/11.27/lock.min.js"></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
20

Thanks for providing that context!

21

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 https://your_app.your_region.auth0.com/.well-known/jwks.json) 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

5 Likes