在 JWT Payload 中存储用户角色信息是可行的，但必须确保 Payload 经过强签名算法保护且不应包含敏感隐私数据。适用场景为无状态认证架构，风险边界在于令牌泄露会导致角色信息暴露且权限变更存在延迟。
先说结论：JWT Payload 可以存储角色信息，但需配合签名验证、短过期时间和权限变更刷新机制使用。
- 先判断：确认业务是否允许权限信息缓存至令牌过期，避免强一致性场景误用。
- 优先做：使用 RS256 非对称算法签名，避免在 Payload 中明文存储密码等敏感信息。
- 再验证：服务端必须校验签名有效性、过期时间及签发者，防止令牌篡改。
快速处理思路
若需在 JWT 中存储角色，建议采用最小化原则，仅存储必要角色标识而非详细权限列表。对于权限变更频繁的场景，应结合短期 Access Token 与长期 Refresh Token 机制，确保角色更新后旧令牌尽快失效。服务端解析令牌时，不能仅依赖 Payload 内容，必须校验签名密钥是否匹配。
为什么会这样
JWT Payload 默认仅经过 Base64 编码而非加密，任何获取令牌的人均可解码查看内容。公开资料中没有看到可靠的量化数据表明编码本身能提供安全性，因此敏感信息泄露风险真实存在。此外，JWT 无状态特性意味着服务端不保存令牌状态，用户权限变更后，旧令牌在过期前仍携带旧角色信息，导致权限更新延迟。
分步处理
第一步：定义 Payload 结构。仅包含用户标识（如 user_id）和角色代码（如 role: "admin"），避免存入姓名、手机号等隐私数据。
第二步：选择签名算法。优先使用 RS256 非对称算法，私钥签名、公钥验签，避免 HS256 对称算法密钥泄露导致伪造令牌。
第三步：设置过期时间。访问令牌过期时间建议设置在 15 分钟到 1 小时之间，降低令牌被盗用后的风险窗口。
第四步：服务端校验逻辑。接收请求后，先验证签名有效性，再检查 exp 字段是否过期，最后提取角色信息进行权限判定。
怎么验证是否生效
使用在线 JWT 解码工具或本地脚本解码令牌，确认 Payload 中角色字段可见但签名部分无法被篡改。修改 Payload 中任意字符后重新请求接口，服务端应返回 401 或 403 错误，证明签名校验生效。检查日志确认令牌过期后无法继续使用，且权限变更后重新登录获取的新令牌包含更新后的角色。
常见坑
部分 SDK 在解析令牌时默认跳过签名验证，需显式开启 verify 选项。算法混淆攻击可能导致服务端误用公钥作为 HMAC 密钥验签，应强制指定允许的算法列表。令牌吊销机制缺失会导致用户注销后旧令牌仍可访问资源，需结合黑名单或短令牌策略应对。
常见问题
JWT Payload 中的角色信息能加密吗？
可以，但需使用 JWE 标准而非普通 JWT。普通 JWT 仅签名不加密，若需保密内容应选用 JWE 或在传输层使用 HTTPS 保护。
用户权限变更后如何立即生效？
JWT 本身无法主动失效，需通过缩短 Access Token 有效期并结合 Refresh Token 机制，或在服务端维护令牌黑名单强制吊销。
可以在 JWT 中存储详细权限列表吗？
不建议，HTTP 头部大小有限制，过多数据可能导致请求失败。仅存储角色标识，具体权限映射建议留在服务端处理。
参考来源
- JWT 全方位解析：原理、安全与最佳实践-CSDN 博客
- JWT 与 OAuth2 身份认证:10 个安全实现技巧与最佳实践-CSDN 博客
- JWT 认证机制解析与安全最佳实践
- JWT 安全测试终极指南：从漏洞识别到 Payload 实战利用