IdentityServer4+ASP.NET Core 2持有效令牌仍401，负载均衡内存存储是否相关？

先给你说最可能的原因——就是你这套负载均衡+内存令牌存储的组合踩了IdentityServer4的默认配置坑，下面给你拆解所有可能的问题和对应的解决办法：

1. 负载均衡下内存存储导致签名密钥不一致（最大概率） #

IdentityServer4默认会在每台服务器的内存里自动生成独立的签名密钥，用来签名和验证JWT令牌。现在你的用户从服务器A拿到了用A的密钥签名的令牌，请求API时被负载均衡转发到服务器B，B用自己内存里的密钥去验证，自然认不出这个令牌的合法性，直接返回401。

解决办法：
把IdentityServer的签名密钥改成两台服务器共享的固定密钥，不要用默认的自动生成内存密钥。推荐用证书（生产环境）或者对称密钥（测试环境）：

// 在IdentityServer的Program.cs/Startup.cs里配置
builder.Services.AddIdentityServer()
    // 用证书（生产环境首选）
    .AddSigningCredential(new X509Certificate2(@"C:\certs\your-cert.pfx", "cert-password"))
    // 或者用对称密钥（测试用，密钥要足够长且复杂）
    // .AddSigningCredential(new SymmetricSecurityKey(Encoding.UTF8.GetBytes("your-32-character-or-longer-shared-secret")))
    .AddInMemoryApiResources(...)
    .AddInMemoryClients(...);

同时，你的API端在配置JWT验证时，必须和IdentityServer用完全相同的密钥/证书，才能正确验证令牌签名。

2. 角色声明名称不匹配 #

API端配置的角色声明名称，和IdentityServer返回的令牌里的角色声明名称对不上，导致API识别不出用户的角色X，从而触发授权拒绝。

比如IdentityServer默认返回的角色声明是role，但有些API因为继承了旧的.NET身份认证配置，可能期望的是http://schemas.microsoft.com/ws/2008/06/identity/claims/role这种长格式的声明名称。

解决办法：

• 检查API端的JWT验证配置，确保RoleClaimType和IdentityServer返回的一致：

// API端的Program.cs配置
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Authority = "https://your-identityserver-domain";
        options.TokenValidationParameters = new TokenValidationParameters
        {
            RoleClaimType = "role", // 要和IdentityServer里用的声明名称一致
            ValidAudience = "your-api-resource-name"
        };
    });

• 同时确认IdentityServer在给用户添加角色声明时用的是正确的名称，比如在ProfileService里：

public async Task GetProfileDataAsync(ProfileDataRequestContext context)
{
    var user = await _userManager.GetUserAsync(context.Subject);
    var roles = await _userManager.GetRolesAsync(user);
    // 这里的"role"要和API端的RoleClaimType对应
    context.IssuedClaims.AddRange(roles.Select(r => new Claim("role", r)));
}

3. 令牌的受众（Audience）与API配置不匹配 #

如果令牌里的aud字段（代表这个令牌允许访问的资源）和API端配置的ValidAudience不一致，API会直接拒绝访问。

解决办法：

• 检查IdentityServer里的ApiResource配置的Name，必须和API端的ValidAudience完全一致：

// IdentityServer的ApiResource配置
new ApiResource("api-order-service", "Order Management API")
{
    Scopes = { "api-order-service.read", "api-order-service.write" }
}
// API端的配置要对应
options.TokenValidationParameters.ValidAudience = "api-order-service";

• 同时确认客户端请求令牌时，请求的Scope包含了该API的权限范围，否则令牌里不会包含对应的受众信息。

4. 负载均衡会话粘性（次要可能性） #

虽然你已经拿到了有效令牌，但如果负载均衡没有配置会话粘性，用户登录时在服务器A创建的会话数据（比如Consent同意记录）只存在A的内存里，后续如果被转发到B服务器，可能会出现隐性的权限问题，但这个情况更多影响登录流程，而非令牌验证后的API访问，所以优先级靠后。如果前面的排查都没问题，可以尝试开启负载均衡的会话粘性测试。

内容的提问来源于stack exchange，提问作者Adel.D