Allow specifying exact authentication schemes in AuthenticationMiddleware. #55766
Labels
api-suggestion
Early API idea and discussion, it is NOT ready for implementation
area-security
enhancement
This issue represents an ask for new feature or an enhancement to an existing one
Milestone
Background and Motivation
I believe there are many different web applications that support more than one authentication mode as default like "if there is an API-key specified, use it, otherwise fallback to cookies". I had such services in development and had an urge to know current user for logging purposes before authorization takes places and cancells requests with 403. It instantly comes to mind that best place for such middleware is between
app.UseAuthentication()
andapp.UseAuthorization()
steps, but the main problem is that you can specify multiple default authentication schemes only for authorization scheme, i.e. authentication step can handle only single authentication scheme(cookies in our case), while API-key is considered only on authorization step.Proposed API
The idea is to allow specifying exact list of authentication schemes in middleware so they are handled in same way as they are handled in authorization.
namespace Microsoft.AspNetCore.Builder; public static class AuthAppBuilderExtensions { + public static IApplicationBuilder UseAuthentication(this IApplicationBuilder app, params string[] schemes); }
Usage Examples
In given case this middleware should first challenge "api-key" scheme. If it succeeds, then step is finished, otherwise fallback to "cookies". This overload is not supposed to consider default authentication scheme since all schemes are specified explicitly, i.e. if default authentication scheme is "jwt", then only "api-key" and "cookies" are used, "jwt" is ignored since it is not specified. If default scheme is among the specified schemes, then it should be applied exactly in order as it is specified in schemes list. I.e. being a default scheme doesn't interfere in any way with this middleware.
Also this approach should work better with branched middleware chains since you can specify exact auth scheme to reach them. Like in main branch you use scheme "cookies", for health or prometheus branch you use scheme "api-key". Current approach doesn't support any configuration for middleware.
Risks
Since this overload is optional and new, it is not supposed to break anything.
The text was updated successfully, but these errors were encountered: