Blocked by CORS policy: Response to preflight request doesn't pass access control check

Using ASPNET 7, login in via swagger works fine but when I try to make request to an authorized endpoint I get:

	
Failed to fetch.
Possible Reasons:

CORS
Network Failure
URL scheme must be "http" or "https" for CORS request.

When I inspect via browsers console I see

Access to fetch at 'https://<texthere>.us.auth0.com/<alotmoretexthere>' (redirected from 'https://<domainname>/api/<endpointroute>') from origin 'https://<domainname>' 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.

I assumed this was my application that had Cors issue so I added

builder.Services.AddCors(options =>
{
    options.AddDefaultPolicy(policy =>
    {
        policy.AllowAnyHeader();
        policy.WithOrigins("https://localhost:7243", "https://<domainname>",
            $"https://{builder.Configuration["Auth0:Domain"]}");
        policy.AllowAnyMethod();
        policy.AllowCredentials();
    });
});

granted maybe a bit too open, but this is just for testing. And yet it fails :confused:

What I did find is that if I actually go on the link from the console (https://<texthere>.us.auth0.com/<alotmoretexthere>) It returns a 405

This page isn’t workingIf the problem continues, contact the site owner.
HTTP ERROR 405

BUT then the CORS issue disappears on subsequent calls. This obviously doesn’t solve the problem because the moment I clean my cookies I am back at the same problem.

— EDIT
I spent quiet a bit of time testing different options for Allowed Origins, Allowed Web Origins etc. but since it does work once the cookies are set correctly (by going to that link manually) I doubt its a setting I am missing.

After further investigation I see it tries to make OPTIONS type http request to https://<texthere>.us.auth0.com/<alotmoretexthere> and gets 404 meanwhile when I manually go to that link it returns a 200 and calls the endpoint I called in the first place but instead of calling it with POST (the endpoint is of POST type) it calls it with GET hence the 405, I am assuming it losses the type when I go on the link manually somehow and GET is the default. The big question here is why does it return 404 when calling https://<texthere>.us.auth0.com/<alotmoretexthere> with OPTIONS type when calling the endpoint via swagger in the first place.

Deleting cookies from .AspNetCore.Cookies is what causes it to break again after manually clicking the link :confused:

After many hours of investigating based on many articles I read on this topic (by Auth0 and the community) I realised that using

builder.Services
    .AddAuth0WebAppAuthentication(options =>
    {
        options.Domain = builder.Configuration["Auth0:Domain"]!;
        options.ClientId = builder.Configuration["Auth0:ClientId"]!;
    });

for some reason didn’t work for me. Instead I created “CustomAPI” in the APIs section and used

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
}).AddJwtBearer(options =>
{
    options.Authority = "https://stuffherez.us.auth0.com/";
    options.Audience = "https://domainhere";
});

leaving swagger stuff connected to application as before. I am yet to understand what good is

builder.Services
    .AddAuth0WebAppAuthentication(options =>
    {
        options.Domain = builder.Configuration["Auth0:Domain"]!;
        options.ClientId = builder.Configuration["Auth0:ClientId"]!;
    });

in addition, it wasn’t helpful that auth0’s own documentation was so often using very different methods to solve the same issue, in one place i saw AddAuth0WebAppAuthentication used meanwhile in another it was omitted all together etc etc


I think the whole thing was me confusing the APIs with Application functionality in Auth0, after realising this I must say Its quiet difficult to square this based on what documentation is out there a simple google search for “AspNet swagger Auth0 oauth” gets u 10 solutions all of which are different (and quiet few are by auth0 itself.)

1 Like

Thanks for sharing all that feedback and context i will make sure to relay it to appropriate team! And thank you for sharing the solution with the rest of community as well!