敏感数据不应该放入标准 JWT Payload 中传输。JWT 载荷默认仅经过 Base64URL 编码而非加密，任何持有 Token 的人均可解码查看内容。仅在必须使用且配合 JWE（JSON Web Encryption）标准加密载荷时才可考虑，但最佳实践是将敏感信息保留在服务端会话中。
先说结论：标准 JWT 不具备保密性，严禁在 Payload 中明文存储密码、身份证号等敏感信息。
- 先判断：确认业务是否真的需要在客户端存储敏感数据，绝大多数场景应使用服务端会话。
- 优先做：若必须传输，使用 JWE 标准加密 Payload 或仅存储非敏感的用户 ID 引用。
- 再验证：通过 Base64 解码工具检查 Token 内容，确保无明文敏感字段。
命令速用版
使用命令行或在线工具解码 JWT 载荷，检查是否存在敏感字段。
echo <your_jwt_token> | cut -d '.' -f 2 | base64 -d将<your_jwt_token>替换为实际 Token 字符串，命令会输出 Payload 的明文 JSON 内容。
为什么会这样
JWT 的签名机制仅保证数据完整性，不提供机密性保护。JWT 标准（RFC 7519）定义 Payload 部分仅进行 Base64URL 编码，这是一种可逆的编码方式而非加密算法。签名（Signature）的作用是防止数据被篡改，确保数据来源可信，但无法阻止第三方读取数据内容。因此，任何包含在 Payload 中的信息对持有 Token 的人都是可见的。
分步处理
按照最小权限原则清理 JWT 内容并加固传输链路。
- 移除敏感字段：检查代码中生成 Token 的逻辑，删除 password、phone、id_card 等字段，仅保留 sub（用户 ID）、exp（过期时间）、role（角色）等非敏感声明。
- 使用服务端映射：若需获取用户详细信息，仅在 JWT 中存储用户唯一标识（如 UUID），敏感数据保留在服务端数据库或缓存中，通过接口鉴权后查询。
- 强制 HTTPS 传输：配置 Web 服务器强制启用 HTTPS，防止 Token 在网络传输过程中被中间人截获。
- 设置短有效期：将 JWT 的 exp claims 设置为较短时间（如 15 分钟至 2 小时），降低 Token 泄露后的风险窗口。
怎么验证是否生效
通过解码工具确认 Token 内容不包含敏感信息，并监控传输协议。
- 内容检查：使用 jwt.io 或上述命令行工具解码当前生产环境的 Token，确认 Payload 中无明文敏感数据。
- 传输检查：在浏览器开发者工具 Network 面板中，确认所有携带 Authorization 头的请求均为 https 协议。
- 日志审计：检查服务端日志，确认没有将完整 JWT 记录到明文日志文件中，避免日志泄露导致 Token 被盗。
常见坑
- 误以为签名等于加密：签名只能防篡改，不能防读取。不要依赖 HS256 或 RS256 算法来隐藏数据。
- 过度信任前端传来的 JWT：即使 Token 未泄露，也不要直接将 Payload 中的角色字段用于核心权限判断，应在服务端二次验证。
- 忽略 Token 存储安全：避免将 JWT 存储在 localStorage 中以防 XSS 攻击窃取，推荐存储在 HttpOnly Cookie 中或内存中。
常见问题
可以用 JWE 加密 Payload 吗？
可以，但会增加实现复杂度。JWE（JSON Web Encryption）标准支持加密 Payload，但需要管理加密密钥，且调试困难，通常不如服务端会话方案简便。
开启了 HTTPS 就可以存敏感数据吗？
不可以。HTTPS 仅保护传输过程，一旦 Token 到达客户端或被日志记录，敏感数据仍可能泄露。
JWT 过期了还能用吗？
不能。服务端会验证 exp 声明，过期 Token 会被拒绝。但需注意，JWT 一旦签发无法主动失效，需配合黑名单机制。
参考来源
- 全面解析 JWT 技术 - 安全性考虑
- JWT 存储敏感信息导致数据泄露风险 - 问题背景与基本认知
- 面试必备：理解 JWT 鉴权的应用场景及使用建议 - RFC 7519 标准说明
- JWT 认证机制解析与安全最佳实践 - 不存储敏感数据建议
- JWT(JSON Web Token) 详解：原理、应用与最佳实践 - 载荷存储用户声明