Should JwtBearerHandler implement SignInAuthenticationHandler?

[yorickdewid]

Currently ASP.NET Core JwtBearer does not offer sign in support, but only Authentication and Challenge handlers. When building an API there is really no way to generate JWT tokens except when using an identity server. Simple APIs often do not require an entire identity server setup with full OAuth 2.0 and an OIDC provider.

A quick search around the internet learns that there is many (sometimes disastrous) tutorials showing how to write a simple JWT token generator. Putting security concepts to a large developer base may not yield great results, especially in an otherwise secure framework.

Is there any specific reason why the JWT bearer handler cannot sign in principals, and creates a basic JWT token for local authentication?

The implementation would be most trivial, in fact I've a proof of concept ready. The interface would be much like how cookie authentication is done for local principals.

var claims = new List<Claim>
{
    new Claim(ClaimTypes.Name, "bob")
};

var principal = new ClaimsPrincipal(new ClaimsIdentity(claims, JwtBearerDefaults.AuthenticationScheme));
            
IAuthenticationService authenticationService = ServiceProvider.GetRequiredService<IAuthenticationService>();
await authenticationService.SignInAsync(HttpContext, JwtBearerDefaults.AuthenticationScheme, principal, null);

The code stub above would attach a Bearer token to the Authorization HTTP header. There is little to no configuration required to generate JWT tokens.

[Tratcher]

We've avoided that in the past because there's no standard way to deliver the generated token to the client. The response is app specific. I'd expect most apps to communicate this in a Json body. The Authorization header is for requests, www-authenticate is for responses but it's only supposed to describe auth schemes, not deliver credentials.

What you can do is resolve the JwtBearer options from DI into your API controller and use those to generate a Jwt.

[yorickdewid]

There is no standard way to deliver JWT tokens apart from OIDC. However the response is not that app specific. I reckon most of the smaller apps will just instantiate a JwtSecurityToken and generate the token with the JwtSecurityTokenHandler. However, there is still a lot that can go wrong, and you don't need to look far (stackoveflow) to find strange solutions like encrypting JWT tokens, using invalid signatures, not checking any of the JWT attributes etc, injecting tokens in middleware, sending cookies over an API etc.

I hear you, but isn't there anything we can do to make JWT token generation less error prone/more secure? For example, there is no standardized way to do cookie authentication either, yet ASP.NET MVC offers a proficient solution that works out of the box.

What about a service which wraps the JwtSecurityTokenHandler that can generate tokens? JwtSecurityTokenHandler is already half way there since it can generate tokens. One would only need to resolve this service from the DI and call GenerateToken() on it. Just a thought.

[yorickdewid]

@Tratcher

[Tratcher]

The cookie comparison isn't accurate, browsers have standard behavior around the Set-Cookie and Cookie headers that make them flow automatically. The contents of the cookie doesn't matter to them.

@javiercn may be able to comment on various patterns we've used for generating JWTs for SPA apps.