.NET 4.7.2 WebApi用JWT Bearer认证注入角色仍返回401错误

不带角色限制的[Authorize]能正常生效，说明Keycloak的AccessToken本身验证没问题，但带Roles的接口返回401，核心问题在于ASP.NET没有正确识别到角色声明——要么是角色声明的类型不对，要么是添加角色的时机没踩对。

方案1：正确映射Keycloak的角色声明 #

Keycloak的AccessToken里，角色一般存在realm_access.roles（全局角色）或resource_access.{你的客户端ID}.roles（客户端专属角色）里，默认JWT中间件不会自动把这些字段转成ASP.NET认可的ClaimTypes.Role，得手动处理：

修改Startup里的JWT配置，用OnTokenValidated事件解析角色：

app.UseJwtBearerAuthentication(
    new JwtBearerAuthenticationOptions
    {
        AuthenticationMode = AuthenticationMode.Active,
        TokenValidationParameters = new TokenValidationParameters()
        {
            ValidAudience = apiIdentifier,
            ValidIssuer = domain.TrimEnd('/'),
            IssuerSigningKeyResolver = (token, securityToken, kid, parameters) => keyResolver.GetSigningKey(kid),                      
        },
        Events = new JwtBearerEvents
        {
            OnTokenValidated = context =>
            {
                // 解析全局角色
                var realmAccess = context.Principal.Claims.FirstOrDefault(c => c.Type == "realm_access")?.Value;
                if (!string.IsNullOrEmpty(realmAccess))
                {
                    var realmRoles = Newtonsoft.Json.JsonConvert.DeserializeObject<Dictionary<string, List<string>>>(realmAccess);
                    if (realmRoles.TryGetValue("roles", out var roles))
                    {
                        var identity = context.Principal.Identity as ClaimsIdentity;
                        foreach (var role in roles)
                        {
                            identity.AddClaim(new Claim(ClaimTypes.Role, role));
                        }
                    }
                }

                // 解析客户端角色（如果用的是客户端级角色）
                var resourceAccess = context.Principal.Claims.FirstOrDefault(c => c.Type == "resource_access")?.Value;
                if (!string.IsNullOrEmpty(resourceAccess))
                {
                    var resourceRoles = Newtonsoft.Json.JsonConvert.DeserializeObject<Dictionary<string, Dictionary<string, List<string>>>>(resourceAccess);
                    if (resourceRoles.TryGetValue(apiIdentifier, out var clientRoles))
                    {
                        if (clientRoles.TryGetValue("roles", out var roles))
                        {
                            var identity = context.Principal.Identity as ClaimsIdentity;
                            foreach (var role in roles)
                            {
                                identity.AddClaim(new Claim(ClaimTypes.Role, role));
                            }
                        }
                    }
                }
                return Task.CompletedTask;
            }
        }
    });

方案2：调整自定义Provider的逻辑 #

你现在用的ValidateIdentity方法可能执行时机晚于角色校验，或者没正确更新认证票据。改一下方法逻辑：

public class CustomOAuthBearerProvider : OAuthBearerAuthenticationProvider
{
    public override Task ValidateIdentity(OAuthValidateIdentityContext context)
    {
        var identity = context.Ticket.Identity as ClaimsIdentity;
        // 明确添加ClaimTypes.Role类型的声明
        identity.AddClaim(new Claim(ClaimTypes.Role, "Admin"));
        // 更新认证票据，确保新的声明被生效
        context.Ticket = new AuthenticationTicket(identity, context.Ticket.Properties);
        return base.ValidateIdentity(context);
    }
}

方案3：修正控制器的拼写错误 #

你的控制器代码里public Strig Test()是拼写错误，应该是public string Test()，虽然这不是401的直接原因，但会导致编译失败，得先改过来：

[Route("test")]
[Authorize(Roles = "Admin")]
public string Test()
{
   return "Hello";
}

1. 用jwt.io解码你的AccessToken，看看里面有没有Admin角色，注意大小写是敏感的。
2. 加个测试接口，返回当前用户的所有声明，确认角色声明是否正确：

[Route("claims")]
[Authorize]
public IHttpActionResult GetClaims()
{
    var claims = User.Claims.Select(c => new { c.Type, c.Value });
    return Ok(claims);
}

调用这个接口，检查有没有类型为http://schemas.microsoft.com/ws/2008/06/identity/claims/role、值为Admin的声明。

内容的提问来源于stack exchange，提问作者ktary