Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom header settings not picked up when using OAuth2 security scheme #1935

Open
mark-buhagiar opened this issue Nov 15, 2024 · 1 comment

Comments

@mark-buhagiar
Copy link

Describe the bug
When using Swashbuckle.AspNetCore and specifying a secutiy schema of type SecuritySchemeType.ApiKey, we are able to customize the header used to send the token using the Name property. However this doesn't seem to work when you have an implicit OAuth2 flow as described in the code below. The OAuth flow works fine, but the token is sent to the api over the Authorization header which is not desired.

OpenApi File To Reproduce
Excerpt from the generates OpenAPI document:

 "securitySchemes": {
      "Bearer": {
        "type": "oauth2",
        "description": "Custom JWT header using the Bearer scheme.",
        "flows": {
          "implicit": {
            "authorizationUrl": "https://login.microsoftonline.com/<<TENANT>>/oauth2/v2.0/authorize",
            "tokenUrl": "https://login.microsoftonline.com/<<TENANT>>/oauth2/v2.0/token",
            "scopes": {
              "<<MY_SCOPE>>": "App Scope"
            }
          }
        }
      }
    }

Expected behavior
The custom header x-custom-auth-token should be used in place of Authorization

Screenshots/Code Snippets

builder.Services.AddSwaggerGen(options =>
{
    options.AddSecurityDefinition(JwtBearerDefaults.AuthenticationScheme, new OpenApiSecurityScheme
    {
        Type = SecuritySchemeType.OAuth2,
        Scheme = JwtBearerDefaults.AuthenticationScheme,
        Description = "Custom JWT header using the Bearer scheme.",
        Name = "x-custom-auth-token",
        In = ParameterLocation.Header,

        Flows = new OpenApiOAuthFlows
        {
            Implicit = new OpenApiOAuthFlow()
            {
                AuthorizationUrl = new Uri("https://login.microsoftonline.com/<<TenantId>>/oauth2/v2.0/authorize"),
                TokenUrl = new Uri("https://login.microsoftonline.com/<<TenantId>>/oauth2/v2.0/token"),
                Scopes = new Dictionary<string, string> { { "<<Scope>>", "Default scope" } }
            }
        }
    });

    options.AddSecurityRequirement(new OpenApiSecurityRequirement
    {
        {
            new OpenApiSecurityScheme
            {
                Name = "x-custom-auth-token",
                Reference = new OpenApiReference{
                    Type = ReferenceType.SecurityScheme,
                    Id = JwtBearerDefaults.AuthenticationScheme
                }
            }, new string[]{ }
        }
    });
});

app.UseSwaggerUI(options =>
{
    options.OAuthAppName("Testing");
    options.OAuthClientId("<<ClientID>>");
    options.OAuthClientSecret("<<ClientSecret>>");
    options.OAuthUsePkce();
});

Additional context
This issue was originally raised here: domaindrivendev/Swashbuckle.AspNetCore#3138. Investigation by @martincostello shows that the header isn't in the OpenAPI document, but it's on the OpenApiDocument in memory.

@microsoft microsoft deleted a comment from Pshon1 Nov 19, 2024
@darrelmiller
Copy link
Member

darrelmiller commented Nov 19, 2024

SwaggerUI doesn't send your bearer token over a custom header because that isn't a supported mechanism. OpenAPI doesn't have the notion of sending OAuth2 bearer tokens anywhere other than via the Authorization header with a bearer scheme. That's how OAuth2 is defined.

You can do OAuth2, or you can do ApiKey. There is no support in OpenAPI for a combination of the two.

I think the fact that in the debugger the OpenApiSecurityScheme shows "in: header" is just an artifact of it being the default value but is not used when the type is OAuth2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants