ShoudValidate for Antiforgery Tokens in Minimal APIs

[ladeak]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Add multiple authentication providers configured. (ie. SAML+cookie and OAuth+JWT).
Add the built in Antiforgery CSRF protection.
Endpoints can accept requests using either authentication method.

For the Antiforgery token validator, I would like to have an easy way to configure when to run validation or not, so that I can disable it when the client uses a JWT token.

Describe the solution you'd like

An override option for the built in middleware or exposing a ShouldValidate() Func<> option in Add/UseAntiforgery methods.

Additional context

No response

[ladeak]

What I end up doing is taking and customizing the middleware also available in the repo. It would be nice not to know about some of the internals, ie. __AntiforgeryMiddlewareWithEndpointInvoked or AntiforgeryValidationFeature.

One approach idea:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddAuthentication(); // Add multiple schemes
builder.Services.AddAuthorization(); // Add multiple policies, setting default and fallback, etc.
builder.Services.AddAntiforgery();
var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

// Func<T,bool> parameter 👇 to the authentication type of the identity such is one approach
app.UseAntiforgery(Func<HttpContext, bool> ctx => ctx.User.Identity.AuthenticationType == "jwt"); 

app.MapPost("/post", (HttpContext ctx) =>
{
    return "Hello World";
});

Second approach idea:

Another approach could be making the current AntiforgeryMiddleware public with a protected method: ShouldValidate, similar to what the (also non-public) AutoValidateAntiforgeryTokenAuthorizationFilter has.
Then anyone can derive and register the customized middleware in the services.

[MackinnonBuck]

Thanks for reaching out, @ladeak. I've moved this to the backlog so we can collect additional feedback from the community. In the meantime, a custom middleware seems like a valid workaround.

[ladeak]

@MackinnonBuck , creating a workaround is fine but the problematic part is the internal const string of __AntiforgeryMiddlewareWithEndpointInvoked which if changes in this repository, it breaks the workaround.