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-byte-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 频繁被判定为已过期或未生效。
