如何安全地解码 JWT
不通过上传安全地解码 JWT：理解解码揭示什么、为何解码不是验证，以及为 API 安全审查应检查哪些声明（alg、exp、iss、aud、sub）。
快速解答
在本地解码 JWT 以检查头部与载荷声明——算法、过期时间、签发者、受众、主体——并且绝不要将令牌粘贴到不受信任的在线解码器；解码不是验证，签名必须由 API 本身验证。
定义
JWT（JSON Web Token）是一种紧凑的、带签名的声明容器，用于认证与授权流程；在分析中安全使用意味着在本地解码，并且绝不将解码与签名验证混为一谈。
先给答案
在本地解码，检查声明，并记住：解码 ≠ 验证。签名由服务器验证，而非解码器。
1. 解码头部
查看 alg 与 typ。如果不受信任的库或文档显示 alg: none，那是不安全解析的危险信号。
2. 检查载荷声明
审查 exp（绝不要信任过期的令牌）、iat、nbf、iss、aud 与 sub。检查签发者与受众是否匹配预期服务。
3. 绝不上传令牌
只将令牌粘贴到仅限本地的工具中（除非你信任剪贴板，否则也谨慎使用 jwt.io 及类似服务——更好的做法是仅本地）。令牌可能携带权限；像对待密码一样对待它们。
4. 记住局限性
解码揭示声明，而非有效性。解码良好的令牌仍可能是伪造或过期的；验证在服务器端使用签名密钥进行。
5. 继续到 API 安全
审查 API 时，确认令牌在服务端被验证（签名、过期时间、签发者、受众），且机密绝不出现在客户端代码中。
有帮助的工具
- JWT 解码器 — 本地解码，不上传。
- Base64 编码/解码器 — 检查令牌的 base64 部分。