JWT authentication returns 401 when policy is set in ASP.NET Core-CodePudding

I am trying to add multiple ways to authenticate users in our app. All but one are working flawlessly. I am able to log in with ASP.NET Core Identity, GitHub, Azure AD, and even API auth, but JWT is giving me a bit of a headache as I always get a 401 response when I pass in an bearer token to the authorization header.

This might have something to do with a custom middleware class that works on this header:

app.UseMiddleware<JwtAuthMiddleware>()
  .UseAuthentication()
  .UseAuthorization()

The middleware class in question:

public class JwtAuthMiddleware
{
  private readonly RequestDelegate _next;

  public JwtAuthMiddleware(RequestDelegate next)
  {
    _next = next;
  }

  public Task Invoke(HttpContext context)
  {
    string authHeader = context.Request.Headers["Authorization"];
    if (authHeader != null)
    {
      string jwtEncodedString = authHeader[7..]; // Fetch token without Bearer
      JwtSecurityToken token = new(jwtEncodedString: jwtEncodedString);
      ClaimsIdentity identity = new(token.Claims, "jwt");
      context.User = new ClaimsPrincipal(identity);
    }

    return _next(context);
  }
}

The identity setup is fairly simple.

services
  .AddAuthentication()
  .AddCookie(/*config*/)
  .AddGitHub(/*config*/)
  .AddJwtBearer(/*config*/)
  .AddAzureAd(/*config*/);

string[] authSchemes = new string[]
{
  IdentityConstants.ApplicationScheme,
  CookieAuthenticationDefaults.AuthenticationScheme,
  GitHubAuthenticationDefaults.AuthenticationScheme,
  JwtBearerDefaults.AuthenticationScheme,
  "InHeader"
};

AuthorizationPolicy authnPolicy = new AuthorizationPolicyBuilder(authSchemes)
.RequireAuthenticatedUser()
.Build();

services.AddAuthorization(options =>
{
  options.FallbackPolicy = authnPolicy;
});

I also set a filter in AddMvc:

.AddMvc(options =>
 {   
  AuthorizationPolicy policy = new AuthorizationPolicyBuilder(authSchemes)
  .RequireAuthenticatedUser()
  .Build();

  options.Filters.Add(new AuthorizeFilter(policy));
})

JWT works when options.FallbackPolicy is not set. Otherwise, I get a 401 response. Inspecting the DenyAnonymousAuthorizationRequirement in debug mode confirms this as there is no principal set with the right claims filled out. So it looks like context.User is ignored or reset.

Ideally, I would want to get rid of JwtAuthMiddleware altogether, but I still have to figure out how to combine JWT with cookie authentication in this particular setup. Any thoughts?

CodePudding user response：

So: some clients will be sending a cookie, and some will be sending Authorize header with a bearer token.

These are authentication schemes that you set up with AddAuthentication.

After that you need to set up authorization (AddAuthorization) to grant access to users who are authentication with either of these schemes.

(Authentication means checking that you are who you say you are (users), authorization means what you are and aren't allowed to do (roles) -- it's confusing.)

CodePudding user response：

You don't need to use this custom JwtAuthMiddleware and define the custom ClaimsPrincipal like that. The problem is that you are just extracting the claims from the token. Setting the ClaimsPrincipal like that wouldn't automatically authenticate the user i.e. Context.User.Identity.IsAuthenticated would be false. Hence you get 401.

The token needs to be validated. You are already using AddJwtBearer which you can customize the code like below if you haven't done that.

JWT bearer authentication performs authentication automatically by extracting and validating a JWT token from the Authorization request header. However, you need to set the TokenValidationParameters which tells the handler what to validate.

services
.AddAuthentication()
.AddJwtBearer("Bearer", options =>
{
    // you don't have to validate all of the parameters below
    // but whatever you need to, but see the documentation for more details
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidIssuer = config.JwtToken.Issuer, // presuming config is your appsettings
        ValidateAudience = true,
        ValidAudience = config.JwtToken.Audience,
        ValidateIssuerSigningKey = true,
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(config.JwtToken.SigningKey))
    };
})

However, there is a caveat. When combining multiple authentication mechanisms, you need to utilise multiple authentication schemes. They play a role in defining the logic to select the correct authentication mechanism. That is because you can call AddJwtBearer or AddCookie multiple times for different scenarios. If the scheme name is not passed, it would try to utilize the default scheme and the authentication will fail, as it would have no way of knowing which mechanism to use JWT or AzureAd as they both use the Bearer token.

You mentioned that JWT works when FallbackPolicy is not set but you get 401 otherwise. That is because your authorization policy requires a user to be authenticated. The user was never authenticated as I mentioned in the beginning. If FallbackPolicy is not set it would work in the context of JWT being passed in the alright, but there is no requirement to check e.g user is authenticated and has a specific claim or role, so it works.

You would need to define an authentication policy scheme and set the ForwardDefaultSelector property of the PolicySchemeOptions. ForwardDefaultSecltor is used to select a default scheme for the current request that authentication handlers should forward all authentication operations to by default.

So basically you need to set the ForwardDefaultSecltor delegate which uses some logic to forward the request to the correct scheme to handle the authentication.

So the above code would change to:

// scheme names below can be any string you like
services
    .AddAuthentication("MultiAuth") // virtual scheme that has logic to delegate
    .AddGitHub(GitHubAuthenticationDefaults.AuthenticationScheme, /*config*/) // uses GitHub scheme
    .AddAzureAd("AzureAd", /*config*/) // uses AzureAd scheme
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, /*config*/) // uses Cookies scheme
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options => { // above code for AddJwtBearer }) // uses Bearer scheme

    // this is quite important to use the same virtual scheme name below
    // which was used in the authentication call.
    .AddPolicyScheme("MultiAuth", null, options =>
    {
        // runs on each request should return the exact scheme name defined above
        options.ForwardDefaultSelector = context =>
        {
            // if the authorization header is present, use the Bearer scheme
            string authorization = context.Request.Headers[HeaderNames.Authorization];
            if (!string.IsNullOrEmpty(authorization) && authorization.StartsWith("Bearer "))
            {
                return "Bearer";
            }

            // custom logic for GitHub
            ...
            return GitHubAuthenticationDefaults.AuthenticationScheme;

            // custom logic for AzureAd
            ...
            return "AzureAd";

            // otherwise fallback to Cookies or whichever is the default authentication scheme
            return CookieAuthenticationDefaults.AuthenticationScheme;
        };
    });

That way, you just remove the JwtAuthMiddleware. AddJwtBearer would automatically add the claims in the Claims object when the token is validated, which you can then use to define custom authorization policies to authorize the user.

I hope that helps.