Browser cached /oauth2/default/v1/keys causing CORB authentication error

I have a SPA configured with OIDC implicit flow. The application has a few environments that I have configured with the same client ID, and I have made sure the correct redirect URLs and CORS/origins are configured. The app uses React and I am using @okta/okta-react with the sign-in widget for user authentication. The different environment urls are in the format {app}-develop.{org}.com and {app}-staging.{org}.com.

I am experiencing some stochastic errors when logging in to multiple environments either concurrently or sequentially and shortly apart. For example, if I log into the develop environment first and then the staging environment, I get this error:

Failed to load https://{org} The 'Access-Control-Allow-Origin' header has a value 'https://{app}-develop.{org}.com' that is not equal to the supplied origin. Origin 'https://{app}-staging.{org}.com' is therefore not allowed access.

The browser is caching the keys response, which includes the Access-Control-Allow-Origin for the develop URL. When I try to login to staging, the browser uses the cached response for keys which leads to the CORB error.

I can bypass this error by:

  1. using an incognito window
  2. clearing the browser cache
  3. checking “disable cache” in the browser dev console

All those options aren’t really acceptable for users to do. How can I bypass this error?

1 Like

Follow up, it seems like “disable cache” does not always work either to bypass this error.

Hey @lawrence, sorry for the delayed response. This is a known issue when using the same client ID for apps hosted on different URLs. It’s something that we are scheduled to fix, but I don’t have a firm date.

The workaround in the meantime is to use separate Okta applications (separate client IDs). Not ideal, but it works. I’ll make sure to post an update here when the caching issue is resolved.

Hi @nate.barbettini. Thanks for the response. Creating separate client IDs was one of the first things I did as a workaround, but the /keys response caching still remains. I was going to look through the okta-react source to see if the client ID is being used in the request to get the jwks. My initial inclination is to say that does not happen.

For others experiencing this same problem, I’ve gotten a response from a Developer Support Engineer stating

This is a known feature gap and we have a few other customers facing the same issue. We raised a JIRA OKTA-156155 (Restricting CORS origins for JWKS endpoints causes caching problems with multiple application (across multiple origins)) internally to handle this feature gap. The latest update on the JIRA says that this would be addressed in the Q4 of this year, but we do not have any solid timelines for now.

1 Like

Hi Lawrence, I have the same problem and it causes some difficulties for the future deployment of our solution.
Do you have a release date of the fix please ?

best regards.

I am still experiencing this issue, therefore I guess it has not been fixed sofar.

Any more updates on this issue? I’m having it, specifically when coming back to the app the next day. During the same day I cannot reproduce.

1 Like

If you are still experiencing issues with CORB and caching on /keys endpoint, please send an email to to have ENABLE_CORS_VARY_HEADER feature enabled.

EDIT: As of September 2019, this feature is available by default and no longer required to be enabled by support. If you still encounter issues, please send an email to

This is now fixed for all orgs. As Dragos said, email support if you still see errors.