17370845950

JWT认证需注册AddAuthentication与AddJwtBearer中间件，配置TokenValidationParameters及32字节密钥；生成token须含exp、iat、iss、aud等标准claim并用UTC时间；UseAuthentication必须在UseAuthorization前；刷新token需业务层实现黑名单校验。

JWT认证在ASP.NET Core Web API中怎么配中间件

ASP.NET Core 6+ 默认不内置 JWT 认证逻辑，必须手动注册 AddAuthentication 和 AddJwtBearer，否则所有带 [Authorize] 的接口都会直接返回 401，且不提示原因。

常见错误是只加了 AddAuthorization 却漏掉 AddAuthentication，或者没指定默认 Scheme。正确顺序和关键参数如下：

• AddAuthentication 必须传入 JwtBearerDefaults.AuthenticationScheme 作为默认 Scheme
• AddJwtBearer 中的 TokenValidationParameters 要显式配置 ValidateIssuer、ValidateAudience、ValidateLifetime 和 ValidateIssuerSigningKey，哪怕设为 false 也要写出来——否则某些版本会因 null 引发 InvalidOperationException
• 密钥必须用 SymmetricSecurityKey 包裹原始字符串（如 new SymmetricSecurityKey(Encoding.UTF8.GetBytes("your-32-byte-secret"))），长度不足 32 字节会导致签名验证失败但错误信息模糊（只报 IDX10501: Signature validation failed）

如何生成符合要求的JWT Token

Token 本身不是黑盒，它由 header.payload.signature 三段 Base64Url 编码组成；后端生成时若 claim 缺失或时间戳格式不对，前端拿到 token 后调用 Authorize 接口仍会 401。

关键点：

• 必须包含 exp（过期时间，UTC）、iat（签发时间）、iss（Issuer）、aud（Audience）等标准 claim，否则 TokenValidationParameters 默认校验会失败
• 使用 JwtSecurityTokenHandler 创建 token，不要手拼字符串；签名算法固定用 SecurityAlgorithms.HmacSha256
• 示例代码片段：

var token = new JwtSecurityToken(
    issuer: "https://myapi.com",
    audience: "https://myclient.com",
    claims: userClaims,
    notBefore: DateTime.UtcNow,
    expires: DateTime.UtcNow.AddMinutes(30),
    signingCredentials: new SigningCredentials(
        new SymmetricSecurityKey(Encoding.UTF8.GetBytes("your-32-b
yte-secret")),
        SecurityAlgorithms.HmacSha256)
);

注意：expires 时间不能早于 notBefore，否则 token 立即失效。

为什么[Authorize]没生效或返回401却不报错细节

ASP.NET Core 默认隐藏 401/403 的具体原因，只返回空响应或通用错误页，导致调试困难。

• 检查是否启用了 app.UseAuthentication() —— 它必须在 UseAuthorization() 之前，且不能放在 UseEndpoints 之后
• 开启详细日志：在 Program.cs 中加 builder.Logging.AddConsole()，并把 Microsoft.AspNetCore.Authentication 日志级别设为 Debug，能看到类似 Bearer was not authenticated. Failure message: IDX10223: Lifetime validation failed 的线索
• 常见静默失败场景：exp 是本地时间而非 UTC、密钥长度不对、issuer/audience 字符串前后有空格、token 从请求头取值时没去掉 Bearer 前缀（虽然中间件通常自动处理，但自定义 handler 容易漏）

刷新 Token 怎么做才安全

JWT 本身不可撤销，所以“刷新”本质是签发新 token 并废弃旧 token 的业务逻辑，框架不提供内置支持。

• 不要在刷新接口里复用登录时的密码校验逻辑；应校验旧 token 的 jti（唯一标识）是否在黑名单中，并检查其是否临近过期（如剩余
• 刷新 token 的有效期建议比访问 token 长（如 7 天），但必须存储 jti + exp 到 Redis 或数据库，每次刷新前查重、每次登出时删记录
• 刷新接口本身也要加 [Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]，否则无法读取原始 token 中的用户信息

最易被忽略的是时间同步问题：服务器、Redis、客户端设备时间差超过 clockSkew（默认 5 分钟）会导致 token 频繁被判定为已过期或未生效。