C# Web API中如何验证JWT Token确实属于对应登录用户

问题1：用户A的Token交给用户B使用的后果 #

默认的JWT校验逻辑下，服务端仅验证Token的签名合法性、有效期、签发方/受众匹配性，不会主动关联Token和当前请求的实际持有人。只要A的Token仍在有效期内，B持有该Token发起的所有请求都会被服务端判定为A本人发起，B可以访问A权限范围内的所有数据、执行A账号支持的所有操作，本质等同于A的账号被盗用。

问题2：验证Token属于当前请求用户的实现方案 #

• 基础校验逻辑：签发JWT时必须在Payload中写入用户全局唯一标识（如用户ID、唯一用户名），ASP.NET Core中通常将该值存入ClaimTypes.NameIdentifier类型的声明中。服务端完成JWT合法性校验后，直接从Token解析出的用户标识作为当前请求的唯一身份凭据，所有数据查询、权限校验都基于该标识执行，不要使用前端请求中携带的任何用户身份参数，即可避免前端伪造身份的问题。
• 身份一致性校验：如果业务场景需要前端显式传入用户标识（比如查询个人信息接口要求传用户ID），将参数中的用户标识和JWT解析出的唯一标识做对比，二者不一致直接返回403拒绝请求即可，比如B用A的Token同时传自己的用户ID请求接口，对比发现不一致直接拦截。
• 增强防盗用校验：如果要进一步降低Token被盗用后的风险，可以在签发时将当前客户端的UA、IP段的哈希值存入JWT Payload，每次请求校验时将当前请求的对应特征计算哈希后和Token中存储的值对比，不一致直接拦截；同时可以实现Token黑名单机制，用户登出或检测到异常登录时将对应Token存入黑名单，请求时先校验黑名单即可。

ASP.NET Core 中读取JWT用户标识的示例代码 #

// 在Controller中直接从ClaimsPrincipal读取用户ID
var userId = User.FindFirstValue(ClaimTypes.NameIdentifier);
// 后续所有业务逻辑都基于该userId执行

内容的提问来源于stack exchange，提问作者Manoj Prabhakar S