I have an asp.net core application using swagger library
<PackageReference Include="Swashbuckle.AspNetCore" Version="5.6.3" />
Id like to allow the api developers using the /swagger web page to be able to obtain a token using the "ClientCredentials" flow. I have tried the below but am getting an options preflight issue
c.AddSecurityDefinition("oauth2", new OpenApiSecurityScheme
{
Type = SecuritySchemeType.OAuth2,
Flows = new OpenApiOAuthFlows
{
ClientCredentials = new OpenApiOAuthFlow
{
TokenUrl = new Uri(baseAuthURL + "/oauth2/v2.0/token"),
Scopes = new Dictionary<string, string>
{
{ "ABC/.default", "Access read operations" }
},
AuthorizationUrl = new Uri(baseAuthURL + "/oauth2/authorize")
}
}
});
when I click authorize
Upon viewing the console, here is what I see
Access to fetch at 'https://login.microsoftonline.com/ABCD/oauth2/v2.0/token' from origin 'https://localhost:44312' has been blocked by CORS policy: 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.
How can I work around this issue? What changes exactly need to be made to "AddSecurityDefinition" to work around this issue? Is this something that I am even able to work around? (assuming identity provider can support the options preflight request)
Is the only single workaround to create a reverse proxy?
How can I extend the code above to send custom HTTP request headers in the request?
I have searched for hours online of an example of someone successfully using ClientCredentials flow to obtain an oauth token within swaggerUI.
Update 1: What is very strange is that even though the options preflight request is receiving a response with the header access-control-allow-origin : * if I use a chrome extension to override this value to the exact same value, it works around the issue. Its obviously not a solution, but more of an observation. It is very odd that setting the value equal to the exact same value somehow changes the outcome.
Below is a diff of the response headers. Left side without any chrome extension, right side with chrome extension overridding to exact same value. You can see there is no difference. So why might the browser be treating this differently?
I have also tried adding an authorization api proxy using AWS API Gateway, which you can see the response headers set below. This does not work either.