Blazor WASM No Server CORS Error

Questions OAuth/OIDC
1

Hi, all. I’m new to Okta and need some guidance. I’ve created a Blazor WASM app (NET6) that has no server backend. I enabled CORS on the application at the Okta dashboard and added each of the URL’s into the CORS section(localhost:5001,localhost:4280; and prod from Azurewebsites, yet my app still cannot fetch the results. The call to Okta is made fine (per the logs), but the page cannot fetch the results. It happens the same way in dev, stage and prod. This is the error.

Access to XMLHttpRequest at ‘https://dev-8wwjt7jl.us.auth0.com/oath2/default/.well-known/openid-configuration’ from origin ‘https://localhost:5001’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

I’ve read docs, watched videos, downloaded code, and made a ton of progress here, but this last part is a blocker.

Can anyone help? Thanks in advance.

2

Are you using an Okta SDK (or more specifically, Okta’s Blazor sample app) with an Auth0 org (judging by the URL in your example)? If so, I’m not positive how well that combination has been tested, but the correct discovery endpoint for Auth0 should just be https://{yourDomain}/.well-known/openid-configuration. That you are seeing a /default stuck into the middle of that URL makes me assume you use one of Okta’s SDKs that are designed to work with Okta’s Authorization Servers, as Okta has a default server available for all Developer orgs upon their creation.

Like I said, I don’t know if Okta’s SDKs are able to work with an Auth0 instance, so you may want to check out Auth0s guides about this instead of Okta’s, for example How to Build and Secure Web Applications with Blazor and How to Secure Blazor WASM Applications with Auth0. You can also get help from people who are more familiar with Auth0s platform and configurations in their community forum: https://community.auth0.com/

If you want to try to get this working anyway, you can look to set the AuthorizationServerId to string.Empty (see docs) so that, in theory, the correct well-known doc is returned (since the SDK is manually forming the URL based on the OktaDomain and the AuthorizationServerId values), but I don’t know if you will run into other issues down the line if you use an Okta-specific SDK with an Auth0 instance.

3

Hi and thanks for responding. It turns out Okta doesn’t have an OOB solution for that (pretty common) use case. They told me that on The Twitter. I’ve now switched over to Azure AADB2C authentication and all is well.