I’m trying to add a basic redirect login to an existing SPA using the latest okta-auth-js library (7.4.3). I’ve initializing with issuer & clientId from my developer app and I’m calling signInWithRedirect, but instead of the page redirecting I get the following CORS error:
In the OPTIONS call I see “Access-Control-Allow-Headers:
Origin, Content-Type, Accept, X-Requested-With, Authorization, Auth0-Client, X-Request-Language” so the error makes sense but… why isn’t the okta header included in that list?
I can hit the endpoint directly and get a response so it seems to be correct. I’ve searched all afternoon but I see little or no references online to this specific header so I’m at a loss for what else to do. Any Ideas?
I’ve double checked that the correct origin url (and redirect/logout/etc) is set in the app, both for localhost and my staging server.
I don’t think that’s what the issue is as it’s not the usual access-control-allowed-origin error that usually comes up with CORS. This is an Okta-specific header that’s not included in the allowed headers response in the options call.
Strange thing is I tried several different browsers last night, and all but safari had the same issue. Safari is not as strict about CORS so it allowed the call and then performed the redirect but gave me a 404 error instead of the Okta login page.
The 404 url has my issuer endpoint followed by /oauth2/v1/authorize?etc… if I remove “oauth2/v1/“ from the url it resolves to the login page. That url is being generated by the Okta js after the call above that’s failing though so I’m not sure if/how it’s related.
+1 I have this exact same issue. I’m hoping that ensuring Okta’s AuthJs SDK will be compatible with both Workforce Identity Cloud (Okta) and Customer Identity Cloud (Auth0) is on Okta;s roadmap, as it is useful to compare the experience between the two platforms via a test Client.