使用自定义身份验证处理程序时POST请求报400 Bad Request问题排查

1. 变动callCount是否为问题真因？Claim值是否会被用于Antiforgery检查？ #

是的，变动的callCount就是问题的直接原因。ASP.NET Core的防伪造验证默认会将当前用户身份的Claims集合作为令牌验证的核心依据之一：

• 生成防伪造令牌时，系统会对用户的Claims进行哈希计算，并将该哈希嵌入令牌中。
• 验证令牌时，会重新计算当前请求用户的Claims哈希，与令牌中的哈希比对。如果不匹配（比如callCount作为Claim值每次请求都变），就会直接返回400 Bad Request，请求根本到不了端点。

简单说：只要你把变动的值放到Claims里，就会破坏防伪造令牌的一致性验证。

2. AD角色转应用角色的实现模式是否正确？ #

你的当前实现存在隐患，正确的模式应该是保证用户Claims的稳定性，仅在身份验证初始化阶段完成角色映射，具体建议如下：

• 优先使用IClaimsTransformation接口来扩展用户Claims：
  这个接口的TransformAsync方法会在用户首次通过Windows Auth验证后执行，负责将AD角色映射为应用专属角色并添加到Claims集合中。生成的Claims会被系统缓存，后续请求复用同一身份对象，不会每次请求都重新生成，从根源避免Claims变动导致的防伪造问题。
• 避免在自定义身份验证处理程序中动态修改Claims：
  如果一定要用自定义处理程序，必须确保Claims只在用户首次验证时生成，后续请求直接复用已验证的身份上下文，绝对不能在每次请求中修改Claims集合（比如测试用的callCount绝对不能作为Claim值加入）。
• 临时修复的根因：
  你固定callCount后正常，本质是让Claims集合保持了一致性，防伪造令牌的哈希比对通过了。但这只是临时绕过，正确的做法还是让Claims集合在用户会话周期内保持稳定。

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