ASP.NET Core 试题 26：JWT Bearer 认证
0501 在 令牌验证参数 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 只验证 JWT 三段格式即可证明令牌可信
- B. 具体信任值来自授权服务器配置，不能仅把 TokenValidationParameters 校验全部关闭
- C. JWT Bearer 应验证签名、发行者、受众和有效期等约束
- D. 观察到“攻击者自签令牌被 API 接受”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 令牌验证参数 的主规则：JWT Bearer 应验证签名、发行者、受众和有效期等约束。选项“具体信任值来自授权服务器配置，不能仅把 TokenValidationParameters 校验全部关闭”是使用规则时要验证的边界，不是规则本身；“只验证 JWT 三段格式即可证明令牌可信”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0502 攻击者自签令牌被 API 接受。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“只验证 JWT 三段格式即可证明令牌可信”定性，不再检查配置、身份或运行时证据。
- B. 先验证“具体信任值来自授权服务器配置，不能仅把 TokenValidationParameters 校验全部关闭”，再依据“JWT Bearer 应验证签名、发行者、受众和有效期等约束”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“具体信任值来自授权服务器配置，不能仅把 TokenValidationParameters 校验全部关闭”。
- D. 以一次成功请求作为结论，不再确认“JWT Bearer 应验证签名、发行者、受众和有效期等约束”是否成立。
查看答案与解析
正确答案B
场景“攻击者自签令牌被 API 接受”指向 令牌验证参数，但症状本身不能证明根因。正确排查应先确认边界“具体信任值来自授权服务器配置，不能仅把 TokenValidationParameters 校验全部关闭”，再用主规则“JWT Bearer 应验证签名、发行者、受众和有效期等约束”解释证据。直接采用误区“只验证 JWT 三段格式即可证明令牌可信”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0503 关于 令牌验证参数，以下哪项说法不成立？
难度： 实战
- A. 只验证 JWT 三段格式即可证明令牌可信
- B. JWT Bearer 应验证签名、发行者、受众和有效期等约束
- C. 具体信任值来自授权服务器配置，不能仅把 TokenValidationParameters 校验全部关闭
- D. 出现“攻击者自签令牌被 API 接受”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“只验证 JWT 三段格式即可证明令牌可信”正是 令牌验证参数 的典型误区。其余三项分别给出了主规则“JWT Bearer 应验证签名、发行者、受众和有效期等约束”、适用边界“具体信任值来自授权服务器配置，不能仅把 TokenValidationParameters 校验全部关闭”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0504 针对“攻击者自签令牌被 API 接受”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“只验证 JWT 三段格式即可证明令牌可信”修改实现，并把一次请求成功作为验收结果。
- B. 按“JWT Bearer 应验证签名、发行者、受众和有效期等约束”修改代码后直接上线，不验证“具体信任值来自授权服务器配置，不能仅把 TokenValidationParameters 校验全部关闭”。
- C. 只验证“具体信任值来自授权服务器配置，不能仅把 TokenValidationParameters 校验全部关闭”，但实现仍继续依赖“只验证 JWT 三段格式即可证明令牌可信”。
- D. 按“JWT Bearer 应验证签名、发行者、受众和有效期等约束”修正实现，并用测试或遥测验证“具体信任值来自授权服务器配置，不能仅把 TokenValidationParameters 校验全部关闭”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：JWT Bearer 应验证签名、发行者、受众和有效期等约束；并确认 具体信任值来自授权服务器配置，不能仅把 TokenValidationParameters 校验全部关闭。继续接受“只验证 JWT 三段格式即可证明令牌可信”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“攻击者自签令牌被 API 接受”这一生产场景能否安全上线。
0505 在 JWT 签名与加密 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 签名会自动加密所有 Claims
- B. 不要把密码或机密放入普通 JWT；需要保密要使用合适加密令牌或服务端存储
- C. 观察到“浏览器开发工具能看到令牌中的用户信息”即可把一次现象当成完整框架契约。
- D. 常见签名 JWT 保证完整性和发行者真实性，但载荷通常可被读取
查看答案与解析
正确答案D
正确答案直接描述 JWT 签名与加密 的主规则：常见签名 JWT 保证完整性和发行者真实性，但载荷通常可被读取。选项“不要把密码或机密放入普通 JWT；需要保密要使用合适加密令牌或服务端存储”是使用规则时要验证的边界，不是规则本身；“签名会自动加密所有 Claims”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0506 浏览器开发工具能看到令牌中的用户信息。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“不要把密码或机密放入普通 JWT；需要保密要使用合适加密令牌或服务端存储”，再依据“常见签名 JWT 保证完整性和发行者真实性，但载荷通常可被读取”判断实现是否符合契约。
- B. 直接按“签名会自动加密所有 Claims”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“不要把密码或机密放入普通 JWT；需要保密要使用合适加密令牌或服务端存储”。
- D. 以一次成功请求作为结论，不再确认“常见签名 JWT 保证完整性和发行者真实性，但载荷通常可被读取”是否成立。
查看答案与解析
正确答案A
场景“浏览器开发工具能看到令牌中的用户信息”指向 JWT 签名与加密，但症状本身不能证明根因。正确排查应先确认边界“不要把密码或机密放入普通 JWT；需要保密要使用合适加密令牌或服务端存储”，再用主规则“常见签名 JWT 保证完整性和发行者真实性，但载荷通常可被读取”解释证据。直接采用误区“签名会自动加密所有 Claims”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0507 关于 JWT 签名与加密，以下哪项说法不成立？
难度： 实战
- A. 常见签名 JWT 保证完整性和发行者真实性，但载荷通常可被读取
- B. 不要把密码或机密放入普通 JWT；需要保密要使用合适加密令牌或服务端存储
- C. 签名会自动加密所有 Claims
- D. 出现“浏览器开发工具能看到令牌中的用户信息”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“签名会自动加密所有 Claims”正是 JWT 签名与加密 的典型误区。其余三项分别给出了主规则“常见签名 JWT 保证完整性和发行者真实性，但载荷通常可被读取”、适用边界“不要把密码或机密放入普通 JWT；需要保密要使用合适加密令牌或服务端存储”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0508 针对“浏览器开发工具能看到令牌中的用户信息”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“签名会自动加密所有 Claims”修改实现，并把一次请求成功作为验收结果。
- B. 按“常见签名 JWT 保证完整性和发行者真实性，但载荷通常可被读取”修正实现，并用测试或遥测验证“不要把密码或机密放入普通 JWT；需要保密要使用合适加密令牌或服务端存储”。
- C. 按“常见签名 JWT 保证完整性和发行者真实性，但载荷通常可被读取”修改代码后直接上线，不验证“不要把密码或机密放入普通 JWT；需要保密要使用合适加密令牌或服务端存储”。
- D. 只验证“不要把密码或机密放入普通 JWT；需要保密要使用合适加密令牌或服务端存储”，但实现仍继续依赖“签名会自动加密所有 Claims”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：常见签名 JWT 保证完整性和发行者真实性，但载荷通常可被读取；并确认 不要把密码或机密放入普通 JWT；需要保密要使用合适加密令牌或服务端存储。继续接受“签名会自动加密所有 Claims”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“浏览器开发工具能看到令牌中的用户信息”这一生产场景能否安全上线。
0509 在 密钥轮换 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. API 通过元数据或配置获取验证密钥，并需处理授权服务器密钥轮换
- B. JWT 签名密钥一旦发布就永远不应轮换
- C. 缓存与刷新要允许新旧密钥合理重叠，同时拒绝未知或不可信来源
- D. 观察到“轮换瞬间大量合法令牌返回 401”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 密钥轮换 的主规则：API 通过元数据或配置获取验证密钥，并需处理授权服务器密钥轮换。选项“缓存与刷新要允许新旧密钥合理重叠，同时拒绝未知或不可信来源”是使用规则时要验证的边界，不是规则本身；“JWT 签名密钥一旦发布就永远不应轮换”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0510 轮换瞬间大量合法令牌返回 401。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“JWT 签名密钥一旦发布就永远不应轮换”定性，不再检查配置、身份或运行时证据。
- B. 先验证“缓存与刷新要允许新旧密钥合理重叠，同时拒绝未知或不可信来源”，再依据“API 通过元数据或配置获取验证密钥，并需处理授权服务器密钥轮换”判断实现是否符合契约。
- C. 只增加重试次数或机器资源，暂不核对“缓存与刷新要允许新旧密钥合理重叠，同时拒绝未知或不可信来源”。
- D. 以一次成功请求作为结论，不再确认“API 通过元数据或配置获取验证密钥，并需处理授权服务器密钥轮换”是否成立。
查看答案与解析
正确答案B
场景“轮换瞬间大量合法令牌返回 401”指向 密钥轮换，但症状本身不能证明根因。正确排查应先确认边界“缓存与刷新要允许新旧密钥合理重叠，同时拒绝未知或不可信来源”，再用主规则“API 通过元数据或配置获取验证密钥，并需处理授权服务器密钥轮换”解释证据。直接采用误区“JWT 签名密钥一旦发布就永远不应轮换”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0511 关于 密钥轮换，以下哪项说法不成立？
难度： 实战
- A. API 通过元数据或配置获取验证密钥，并需处理授权服务器密钥轮换
- B. 缓存与刷新要允许新旧密钥合理重叠，同时拒绝未知或不可信来源
- C. JWT 签名密钥一旦发布就永远不应轮换
- D. 出现“轮换瞬间大量合法令牌返回 401”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“JWT 签名密钥一旦发布就永远不应轮换”正是 密钥轮换 的典型误区。其余三项分别给出了主规则“API 通过元数据或配置获取验证密钥，并需处理授权服务器密钥轮换”、适用边界“缓存与刷新要允许新旧密钥合理重叠，同时拒绝未知或不可信来源”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0512 针对“轮换瞬间大量合法令牌返回 401”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“JWT 签名密钥一旦发布就永远不应轮换”修改实现，并把一次请求成功作为验收结果。
- B. 按“API 通过元数据或配置获取验证密钥，并需处理授权服务器密钥轮换”修改代码后直接上线，不验证“缓存与刷新要允许新旧密钥合理重叠，同时拒绝未知或不可信来源”。
- C. 只验证“缓存与刷新要允许新旧密钥合理重叠，同时拒绝未知或不可信来源”，但实现仍继续依赖“JWT 签名密钥一旦发布就永远不应轮换”。
- D. 按“API 通过元数据或配置获取验证密钥，并需处理授权服务器密钥轮换”修正实现，并用测试或遥测验证“缓存与刷新要允许新旧密钥合理重叠，同时拒绝未知或不可信来源”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：API 通过元数据或配置获取验证密钥，并需处理授权服务器密钥轮换；并确认 缓存与刷新要允许新旧密钥合理重叠，同时拒绝未知或不可信来源。继续接受“JWT 签名密钥一旦发布就永远不应轮换”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“轮换瞬间大量合法令牌返回 401”这一生产场景能否安全上线。
0513 在 令牌撤销 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 自包含访问令牌通常在过期前无需回查服务器，因此即时撤销需要额外设计
- B. 删除数据库会话记录会自动让所有已签发 JWT 失效
- C. 可使用短生命周期、撤销列表、版本号或引用令牌，并权衡可用性与查询成本
- D. 观察到“用户权限撤销后旧令牌仍在有效期内”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 令牌撤销 的主规则：自包含访问令牌通常在过期前无需回查服务器，因此即时撤销需要额外设计。选项“可使用短生命周期、撤销列表、版本号或引用令牌，并权衡可用性与查询成本”是使用规则时要验证的边界，不是规则本身；“删除数据库会话记录会自动让所有已签发 JWT 失效”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0514 用户权限撤销后旧令牌仍在有效期内。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“删除数据库会话记录会自动让所有已签发 JWT 失效”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“可使用短生命周期、撤销列表、版本号或引用令牌，并权衡可用性与查询成本”。
- C. 以一次成功请求作为结论，不再确认“自包含访问令牌通常在过期前无需回查服务器，因此即时撤销需要额外设计”是否成立。
- D. 先验证“可使用短生命周期、撤销列表、版本号或引用令牌，并权衡可用性与查询成本”，再依据“自包含访问令牌通常在过期前无需回查服务器，因此即时撤销需要额外设计”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“用户权限撤销后旧令牌仍在有效期内”指向 令牌撤销，但症状本身不能证明根因。正确排查应先确认边界“可使用短生命周期、撤销列表、版本号或引用令牌，并权衡可用性与查询成本”，再用主规则“自包含访问令牌通常在过期前无需回查服务器，因此即时撤销需要额外设计”解释证据。直接采用误区“删除数据库会话记录会自动让所有已签发 JWT 失效”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0515 关于 令牌撤销，以下哪项说法不成立？
难度： 实战
- A. 自包含访问令牌通常在过期前无需回查服务器，因此即时撤销需要额外设计
- B. 可使用短生命周期、撤销列表、版本号或引用令牌，并权衡可用性与查询成本
- C. 删除数据库会话记录会自动让所有已签发 JWT 失效
- D. 出现“用户权限撤销后旧令牌仍在有效期内”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案C
题目要求选出不成立的说法，答案“删除数据库会话记录会自动让所有已签发 JWT 失效”正是 令牌撤销 的典型误区。其余三项分别给出了主规则“自包含访问令牌通常在过期前无需回查服务器，因此即时撤销需要额外设计”、适用边界“可使用短生命周期、撤销列表、版本号或引用令牌，并权衡可用性与查询成本”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0516 针对“用户权限撤销后旧令牌仍在有效期内”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“删除数据库会话记录会自动让所有已签发 JWT 失效”修改实现，并把一次请求成功作为验收结果。
- B. 按“自包含访问令牌通常在过期前无需回查服务器，因此即时撤销需要额外设计”修正实现，并用测试或遥测验证“可使用短生命周期、撤销列表、版本号或引用令牌，并权衡可用性与查询成本”。
- C. 按“自包含访问令牌通常在过期前无需回查服务器，因此即时撤销需要额外设计”修改代码后直接上线，不验证“可使用短生命周期、撤销列表、版本号或引用令牌，并权衡可用性与查询成本”。
- D. 只验证“可使用短生命周期、撤销列表、版本号或引用令牌，并权衡可用性与查询成本”，但实现仍继续依赖“删除数据库会话记录会自动让所有已签发 JWT 失效”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：自包含访问令牌通常在过期前无需回查服务器，因此即时撤销需要额外设计；并确认 可使用短生命周期、撤销列表、版本号或引用令牌，并权衡可用性与查询成本。继续接受“删除数据库会话记录会自动让所有已签发 JWT 失效”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“用户权限撤销后旧令牌仍在有效期内”这一生产场景能否安全上线。
0517 在 Claims 映射 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 任何名为 role 的 JSON 字段都会自动成为所有方案的角色
- B. JWT Claims 可映射为 ClaimsPrincipal，名称和角色 Claim 类型可配置
- C. 授权策略必须与真实发行 Claim、命名空间和映射设置一致
- D. 观察到“令牌含 roles 数组但 IsInRole 始终为 false”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 Claims 映射 的主规则：JWT Claims 可映射为 ClaimsPrincipal，名称和角色 Claim 类型可配置。选项“授权策略必须与真实发行 Claim、命名空间和映射设置一致”是使用规则时要验证的边界，不是规则本身；“任何名为 role 的 JSON 字段都会自动成为所有方案的角色”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0518 令牌含 roles 数组但 IsInRole 始终为 false。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“任何名为 role 的 JSON 字段都会自动成为所有方案的角色”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“授权策略必须与真实发行 Claim、命名空间和映射设置一致”。
- C. 以一次成功请求作为结论，不再确认“JWT Claims 可映射为 ClaimsPrincipal，名称和角色 Claim 类型可配置”是否成立。
- D. 先验证“授权策略必须与真实发行 Claim、命名空间和映射设置一致”，再依据“JWT Claims 可映射为 ClaimsPrincipal，名称和角色 Claim 类型可配置”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“令牌含 roles 数组但 IsInRole 始终为 false”指向 Claims 映射，但症状本身不能证明根因。正确排查应先确认边界“授权策略必须与真实发行 Claim、命名空间和映射设置一致”，再用主规则“JWT Claims 可映射为 ClaimsPrincipal，名称和角色 Claim 类型可配置”解释证据。直接采用误区“任何名为 role 的 JSON 字段都会自动成为所有方案的角色”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0519 关于 Claims 映射，以下哪项说法不成立？
难度： 实战
- A. 任何名为 role 的 JSON 字段都会自动成为所有方案的角色
- B. JWT Claims 可映射为 ClaimsPrincipal，名称和角色 Claim 类型可配置
- C. 授权策略必须与真实发行 Claim、命名空间和映射设置一致
- D. 出现“令牌含 roles 数组但 IsInRole 始终为 false”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“任何名为 role 的 JSON 字段都会自动成为所有方案的角色”正是 Claims 映射 的典型误区。其余三项分别给出了主规则“JWT Claims 可映射为 ClaimsPrincipal，名称和角色 Claim 类型可配置”、适用边界“授权策略必须与真实发行 Claim、命名空间和映射设置一致”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0520 针对“令牌含 roles 数组但 IsInRole 始终为 false”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“任何名为 role 的 JSON 字段都会自动成为所有方案的角色”修改实现，并把一次请求成功作为验收结果。
- B. 按“JWT Claims 可映射为 ClaimsPrincipal，名称和角色 Claim 类型可配置”修改代码后直接上线，不验证“授权策略必须与真实发行 Claim、命名空间和映射设置一致”。
- C. 按“JWT Claims 可映射为 ClaimsPrincipal，名称和角色 Claim 类型可配置”修正实现，并用测试或遥测验证“授权策略必须与真实发行 Claim、命名空间和映射设置一致”。
- D. 只验证“授权策略必须与真实发行 Claim、命名空间和映射设置一致”，但实现仍继续依赖“任何名为 role 的 JSON 字段都会自动成为所有方案的角色”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：JWT Claims 可映射为 ClaimsPrincipal，名称和角色 Claim 类型可配置；并确认 授权策略必须与真实发行 Claim、命名空间和映射设置一致。继续接受“任何名为 role 的 JSON 字段都会自动成为所有方案的角色”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“令牌含 roles 数组但 IsInRole 始终为 false”这一生产场景能否安全上线。