JWTTokenBase64URL认证

JWT 是什么？如何安全查看 Header 和 Payload

JWT 是由 Header、Payload 和 Signature 组成的令牌。Header 和 Payload 只是 Base64URL 编码，不是加密，任何拿到 token 的人都能解码查看。

ToolGarden 推荐的工具优先在浏览器本地运行，文件和文本不必上传到服务器，适合更注重安全隐私的日常处理。

发布于 2026年7月2日更新于 2026年8月3日约 7 分钟阅读作者 ToolGarden

JWT 常用于登录态和接口鉴权，但它不是加密容器。Header 和 Payload 可以被直接解码查看。

xxxxx.yyyyy.zzzzz
header.payload.signature

JWT 通常由三段组成，中间用点号分隔：第一段是 Header，第二段是 Payload，第三段是 Signature。

三段分别代表什么？

部分	内容	是否加密
Header	算法和 token 类型，例如 alg、typ	不是加密
Payload	业务声明，例如 sub、exp、role	不是加密
Signature	用密钥或私钥计算出的签名	用于验证完整性

解码和验证是两件不同的事

解码只需要把前两段从 Base64URL 还原成 JSON，不需要密钥，所以攻击者也能任意制作一个看起来合理的 Payload。验证则必须由服务端根据允许的算法和可信密钥检查 Signature，并同时校验 exp、nbf、iss、aud 等声明。调试工具显示出字段，只能说明 token 结构可读，不能授予任何信任。

解码成功 ≠ 签名有效
签名有效 ≠ 当前请求有权限

完整判断 = 签名 + 时间 + 签发方 + 受众 + 业务权限

服务端验证时的关键边界

由服务端配置允许的算法，不要直接接受 Header 中 alg 指定的任意算法。
exp 和 nbf 通常使用秒级 Unix 时间戳，比较时要考虑小幅时钟偏差。
RS256 等非对称算法使用公钥验签，HS256 则要求验证方持有同一个 secret。
token 撤销、用户停用和权限变化不会自动写回旧 token，需要额外的会话策略。
签名只保护内容未被修改，不会隐藏 Payload，也不会证明终端设备安全。

排错时可以使用脱敏 token，或在本地查看 Header 与 Payload。生产密钥不应放进浏览器代码、截图、工单或第三方页面。需要验证真实签名时，优先在受控后端或本地开发环境使用与生产相同的验证库和算法白名单。

安全查看 JWT 的注意事项

不要把真实生产 token 粘贴到不可信网站。
Payload 里不要放密码、身份证号、银行卡号等敏感信息。
看到 Payload 不代表 token 有效，还需要检查过期时间和签名。
HS256 验签需要密钥；不要把生产密钥暴露给前端或第三方页面。
本地浏览器解码比上传到服务器的在线工具更适合排查敏感 token。

常见字段怎么看？

字段	含义	排查重点
sub	主体或用户 ID	确认是不是当前用户
exp	过期时间	通常是 Unix 时间戳
iat	签发时间	判断 token 是否过旧
aud	受众	确认是否给当前服务使用
iss	签发方	确认来源是否可信

总结

JWT 的 Header 和 Payload 便于调试，但不应被当作保密空间。安全使用 JWT 的关键是控制签名密钥、过期时间和敏感字段。

常见问题

Q.JWT 里的 payload 是加密的吗？可以放密码吗？

不是加密，只是 Base64Url 编码。任何人拿到 JWT 都可以在浏览器控制台里 atob 出来看到 payload 全部内容。因此绝对不能放密码、身份证号、支付密码、完整银行卡号这类敏感数据。适合放在 payload 的是用户 ID、角色、租户 ID、过期时间等标识信息。如果确实需要传输敏感数据，可以使用 JWE（JSON Web Encryption），它对 payload 做真正的加密；或者把敏感数据留在服务端，JWT 只承担身份识别的职责。

Q.JWT 过期了怎么办？前端要不要自己续签？

常见方案是 access token + refresh token 双令牌：access token 短期（15 分钟到 2 小时）用来访问接口，refresh token 长期（几天到几周）只用来换新的 access token。前端在收到 401 且 refresh token 未过期时，静默调用刷新接口，拿到新 token 后重放原始请求。切忌只用一个长期 JWT，否则一旦泄露就长期有效。也不要在前端定时轮询刷新，容易造成时间窗错乱，出错时用户会突然掉登录。

Q.JWT 和 session cookie 相比，什么时候该选哪个？

Session cookie 依赖服务端存储，登出时清一下 session 即可，安全模型成熟；缺点是难以水平扩展和跨域使用。JWT 是无状态的，天然支持微服务和多端共享，但撤销困难，一般要配合黑名单或短过期时间。经验取舍：单体后端、同域网页首选 session cookie；多个服务、多个客户端、需要跨域或移动端共用后端用 JWT。也可以混合使用，用 JWT 做外部访问、内部服务之间用短期签名令牌。

Q.为什么有人说 JWT 不安全，是危言耸听吗？

并非危言耸听，但也不能一概而论。真正的问题多半来自误用：把敏感数据塞进 payload、用了 alg: none、密钥太短或写在前端、把 JWT 放在 localStorage 被 XSS 偷走、忘了做 exp 校验等。规范使用下 JWT 是安全的：选择强算法（HS256 或 RS256）、密钥足够长、只放非敏感标识、走 HttpOnly Cookie 或短时 access token、服务端记得校验签名和过期。评估安全性时应该看落地方式，而不是抽象地判断技术本身。

Q.解码 JWT 只需要 Base64 就够了，为什么还需要专门的工具？

解出 payload 只是第一步，专业工具通常还会：把时间戳字段（iat、exp、nbf）转成本地时间；标出 payload 是否过期、还有多久过期；识别签名算法；校验签名是否正确（需要提供密钥或公钥）；对常见 claim 名做解释。手工 Base64 解码只能看内容，不能告诉你这个 token 是否还有效、签名是否被篡改。日常开发排查登录问题、复现线上 bug 时，专业工具能显著缩短定位时间。