Cors encountered using Okta Signin Widget

Hi, I have followed the instruction in Sign in to your SPA with the embedded Okta Sign-In Widget | Okta Developer to integrate the sign in widget in my SPA.

And I have also added the trusted origin as

Yet I’m still receiving CORS error:
Access to fetch at ‘’ from origin ‘’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: 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.

What could I do to resolve this error? does the www prefix matter when adding trusted origins?

My Okta Config:
export const config: OktaConfig = {
oidc: {
issuer: ‘issuer /oauth2/default’,
clientId: ‘some client id’,
scopes: [‘openid’, ‘profile’, ‘email’],
redirectUri: ${window.location.origin}/login/callback
widget: {
issuer: ‘issuer /oauth2/default’,
clientId: ‘some client id’,
scopes: [‘openid’, ‘profile’, ‘email’],
redirectUri: ${window.location.origin}/login/callback
useInteractionCodeFlow: true

Okta sign in widget related package version:
@okta/okta-auth-js”: “^6.5.0”,
@okta/okta-react”: “^6.4.3”,
@okta/okta-signin-widget”: “^6.3.1”,


Can you verify that entering the following URL in your browser for your Okta Org pulls up the OIDC discovery document.

It should look similar to the below discovery document for your Okta Org.

If your Okta Org does not have the API Access Management License you will not have the default authorization server. Attempting to access the discovery document via a JS cross origin call will give a CORs error.

Can you also confirm that the org you are testing with is on Okta Identity Engine? You can check which engine you are on by going to https://oktaDomain/.well-known/okta-organization : if you see "pipeline": "v1", you are using an Okta Classic Org that is not compatible with Interaction Code flow and if you see "pipeline" : "idx", you are using an Okta Identity Engine org.

This /interact endpoint is only invoked when useInteractionCodeFlow is enabled, so if you are on a classic org, set this to false.

Thank you both for the help. I resolved the issue by:

  1. changing the issuer to {domain}
  2. Disable the useInteractionCodeFlow
  3. Turns out that the “www” does matter when setting Trusted Origins for CORS
1 Like