Api /oauth2/default/v1/keys causing CORS authentication error

I am developing a SPA application(using @vue/okta-vue) and using okta for authetication. It was working fine until today(2018/12/13).

Today I input my username and password on Okta login page and the login seemed to succeed. Then my redirect uri was invoked and I got the error below

Failed to load https://dev-998107.oktapreview.com/oauth2/default/v1/keys: Response to preflight request doesn’t pass access control check: The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard ‘*’ when the request’s credentials mode is ‘include’. Origin ‘http://localhost:8080’ is therefore not allowed access. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

Making request to url like “https://dev-998107.oktapreview.com/oauth2/default/v1/keys” would be handled by okta-vue and I don’t know what happened

ps: I cleared my browser cache today. I don’t know whether it matters or not. Maybe this issue would existed a few days ago and didn’t happen because of my previous cache.


Hi. I have the exact same problem as of today. Hope for a solution.

1 Like

Same issue. Affecting sites.

1 Like

I am facing the same issue.

You seems to have have the same issue than me.

If I understand the error message, it is a problem with the header received by our browser…
The ’ ‘Access-Control-Allow-Origin’ header should not contains ‘*’ anymore but now the real address server.

NOT VALID : Look at the Chrome version 65 page in the comments

People use the --allow-file-access-from-files at the chrome launcher.

About prod, that means you have to config more precisely the servers list granted for cors exchange, don’t know if it is prod server or okta server.

N.B : This error also happens on Edge.

1 Like

I tried to lunch the Chrome Browser with

Does not change anything… In the same time I think it is Okta side because the following message : The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard ‘*’ when the request’s credentials mode is ‘include’

1 Like

I have the exact same problem, this was working as of yesterday, just started having these issues. We have a client install today and would be a show stopper.

I think it has nothing to do with browser. its totally linked with okta library.

Same issue, was working until yesterday, stopped working today, we’ve got a deployment at 1pm.

Same here i also have deployment today.

Had a customer demo 10 minutes ago.
Great start, couldn’t login!

This should be fixed now. Can you please try again? See https://trust.okta.com/#incident/a9C1Y000000GpJuUAK for more information about this incident.

Thanks, all works fine now.

1 Like

Thank you, tested it again and it works.

1 Like

Now it’s working. Thank you

How did you fix this issue?

Hi @ericpool

The issue was resolved by creating a feature which adds “Vary:Origin” header on /keys endpoint. If you do not see this header in the response from /keys, please send an email to support@okta.com mentioning your Okta subdomain (eg. dev-455123.okta.com) and that you would like to have ENABLE_CORS_VARY_HEADER enabled.

Update: The feature has been enabled by default to all Okta tenants. If you encounter any issues, please send an email to developers@okta.com to further check the configuration with one of our Developer Support engineers.

hi @dragos,
i have already set the origin url. but still i can’t connect