Consider allowing a custom JwtBearerHandler implementation in AddJwtBearer

[paulomorgado]

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.

Sometimes there are simple requires that can be achieved by overriding HandleAuthenticateAsync on JwtBearerHandler.

But getting all functionality is not possible because AddJwtBearer cannot be replicated because it uses a JwtBearerConfigureOptionsthat isinternal`.

Tu use it, I've been replacing the JwtBearerHandler registration:

 services
     .AddAuthentication()
     .AddJwtBearer(authenticationScheme)
     ;

 // Replace JwtBearerHandler with MyTokenHandler
 services.RemoveAll<JwtBearerHandler>();
 services.AddTransient<JwtBearerHandler, MyTokenHandler>();

Because it's registered with services.AddTransient instead of services.TryAddTransient.

Describe the solution you'd like

 services
     .AddAuthentication()
     .AddJwtBearer<MyTokenHandler>(authenticationScheme)
     ;

Additional context

Or just use services.TryAddTransient to register JwtBearerHandler.

[MackinnonBuck]

Thanks for reaching out, @paulomorgado.

Is there a reason that adding handlers for the OnMessageReceived and OnTokenValidated events isn't sufficient, and extending JwtBearerHandler is required?

[paulomorgado]

Thanks for reaching out, @paulomorgado.

Is there a reason that adding handlers for the OnMessageReceived and OnTokenValidated events isn't sufficient, and extending JwtBearerHandler is required?

Hi @MackinnonBuck, would you care to share examples on how would I do the same thing I'm doing in HandleAuthenticateAsync? I need all the configuration and setup done in AddJwtBearer, but the token is not a JWT and I have call user info.

[halter73]

Outside of a few APIs like AddHostedService, AddSingleton, AddScoped, AddTransient, etc. which were designed specifically for adding user-defined service types, it's very unusual for us to expose an "Add..." service API that allows you to replace a default service with a custom one. And I don't think this custom JwtBearerHandler scenario is common enough or bad enough to introduce this kind of API. It could make things a little more confusing for the majority people trying to use JwtBearerHandler without overriding it. If we were to redesign it today, we might make JwtBearerHandler sealed and/or internal and just make sure any necessary extensibility can be done using the events.

I get that the way AddJwtBearer adds some configuration helpers makes this hard if you want to reuse JwtBearerOptions and you want the functionality from JwtBearerConfigureOptions and/or JwtBearerPostConfigureOptions, but if we were to add anything I think it would be adding something along the lines of ConfigureJwtBearer which would still leave you responsible for calling AddScheme for you custom handler.

Your workaround of just calling services.AddTransient<JwtBearerHandler, MyTokenHandler>() doesn't seem that bad to me. Since you're able to override the registration for JwtBearerHandler rather than creating a registration specifically for MyTokenHandler, you don't even need to worry about fixing up AuthenticationOptions.SchemeMap. You can probably even get away with not calling services.RemoveAll<JwtBearerHandler>() since the last registration should win. All said, I'm surprised how easily this works already, and I don't think we need to do more to improve this scenario.

would you care to share examples on how would I do the same thing I'm doing in HandleAuthenticateAsync? I need all the configuration and setup done in AddJwtBearer, but the token is not a JWT and I have call user info.

This seems like a perfect fit for OnMessageReceived. Here's an example of using it to retrieve the access token from the query string, but you could call a user info endpoint instead. It's async. https://medium.com/@sametkarademir244/jwtbearerevents-in-asp-net-core-managing-token-events-04cdeb9dc30d also has a pretty good overview of the events.

Your best bet for a comprehensive understanding is probably to look at the source for JwtBearerHandler.HandleAuthenticateAsync. You'll notice that it calls MessageReceived/OnMessageReceived before doing any validation and it will short circuit if you provide an AuthenticateResult. Combined, this allows you to effectively override all of JwtBearerHandler.HandleAuthenticateAsync using just the OnMessageReceived.

[paulomorgado]

I get that the way AddJwtBearer adds some configuration helpers makes this hard if you want to reuse JwtBearerOptions and you want the functionality from JwtBearerConfigureOptions and/or JwtBearerPostConfigureOptions, but if we were to add anything I think it would be adding something along the lines of ConfigureJwtBearer which would still leave you responsible for calling AddScheme for you custom handler.

JwtBearerPostConfigureOptions is public. If JwtBearerConfigureOptions was also public, I could work with it.

Invoking JwtBearerExtensions.AddJwtBearer to add a dummy scheme would register JwtBearerConfigureOptions.

I might also get away with using reflection to register JwtBearerConfigureOptions.

But the best option would be "adding something along the lines of ConfigureJwtBearer which would still leave you responsible for calling AddScheme for you custom handler".

Your workaround of just calling services.AddTransient<JwtBearerHandler, MyTokenHandler>() doesn't seem that bad to me. Since you're able to override the registration for JwtBearerHandler rather than creating a registration specifically for MyTokenHandler, you don't even need to worry about fixing up AuthenticationOptions.SchemeMap. You can probably even get away with not calling services.RemoveAll<JwtBearerHandler>() since the last registration should win. All said, I'm surprised how easily this works already, and I don't think we need to do more to improve this scenario.

By the way, is it intended that AuthenticationBuilder.AddSchemeHelper registers the service all the time instead of registering with TryAddTransient?

[MackinnonBuck]

Thanks for the explanation, @paulomorgado. We're going to put this in the backlog for now, as this issue would require further API design before we can move forward with it.