将用户标识符放入JWT access token载荷中是否合理？如何正确传递用户标识

问题1：将用户标识符放入access token的Payload中在逻辑上是否存在错误？ #

没有逻辑错误，这是符合JWT规范的行业通用做法。

JWT官方标准RFC7519中明确定义了sub（Subject）声明，作用就是存储请求主体的唯一标识符，你要放的user_id、uuid本质就是给这个字段赋值，完全匹配access token的核心功能：身份认证的本质就是确认「当前请求来自哪个用户」，token里携带用户标识才是完成这个功能的基础。如果token里不存用户标识，网关校验完token有效性之后，后端业务接口根本不知道请求来自谁，还要额外查token和用户的映射关系，平白增加性能损耗和出错概率。

你同事的观点实际上是对access token的功能边界有误解：只要你不在payload里放敏感信息（比如手机号、银行卡号这类需要加密存储的字段），user_id这类非敏感的用户标识放在payload里没有任何安全问题，反而适配你当前的AWS架构：API Gateway做自定义授权方校验JWT签名有效性之后，可以直接把payload里的user_id透传给后端服务，不需要额外的查库操作，链路简洁高效。

问题2：若不将用户标识符放入access token，登录成功时应该通过什么方式传递用户标识符？ #

首先要说明的是，这个前提在绝大多数业务场景下都不成立，如果你确实因为合规、架构规范等特殊要求不能把用户标识放access token里，行业内通用的方案有两种：

• 登录接口返回access token的同时，同步返回用户基础信息结构体，里面包含user_id、uuid等标识，客户端存储在本地安全区域，后续请求通过自定义请求头（比如X-User-Id）或者请求体传递该字段。注意这个方案必须在网关层或者业务逻辑层增加校验逻辑，确保用户传递的user_id和当前access token绑定的用户id完全一致，否则会出现严重的越权漏洞，反而增加开发和维护成本。
• 遵循OIDC协议规范，登录成功后同时返回Access Token和ID Token两个JWT令牌：Access Token仅用于接口权限校验，不携带用户标识；ID Token专门用于存储用户身份信息，客户端解析ID Token即可拿到用户标识。这个方案本质是拆分了两个token的职责边界，适合身份体系、权限逻辑比较复杂的中大型项目，但是和直接把用户标识放Access Token里没有本质的安全差异。

针对你的金融服务项目的实操建议 #

优先选择符合标准、链路简洁的方案：直接把user_id放到JWT的sub声明中，签名算法选用RS256非对称加密，私钥仅保存在你的Node Auth Server中，不要在payload中存储任何敏感信息，既安全又能降低开发成本。

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