JWT 是什么？Header、Payload、Signature 和常见安全误区
JWT 是一种常见的登录和接口鉴权 Token。它看起来像一长串字符，中间用两个点分成三段：
eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMjM0NX0.xxxxx先给结论：JWT 通常不是加密内容。Header 和 Payload 只是经过 Base64URL 编码，任何拿到 Token 的人都可以读到里面的字段；真正防篡改的是 Signature。
BaseToolbox 的 JWT 解码器 可以在浏览器本地格式化 Header 和 Payload，快速检查 exp、iat、iss、aud、sub 等字段。它适合调试和检查内容，但不能替代服务端签名验证。
JWT 的三段分别是什么？
JWT 通常由三部分组成：
| 部分 | 作用 | 常见内容 |
|---|---|---|
| Header | 描述 Token 类型和签名算法 | alg、typ |
| Payload | 存放声明，也就是 claims | 用户 ID、过期时间、签发方、受众 |
| Signature | 用服务端密钥或私钥生成的签名 | 用来判断前两段是否被篡改 |
Header 和 Payload 是可读的。把它们解码成 JSON 后，你就能看到 Token 里包含了什么。Signature 不负责隐藏内容，它负责让验证方发现内容有没有被改过。
为什么 JWT Payload 不是私密的？
很多人第一次看到 JWT 解码结果时会误以为工具“破解”了 Token。其实不是。JWT 的 Payload 本来就是可解码的，这也是为什么不要把密码、银行卡、API Key、身份证号、手机号等敏感信息放进 Payload。
如果业务确实需要加密内容，应该看 JWE，也就是 JSON Web Encryption。JWT/JWS 解决的是签名和完整性，不等于加密。
常见的 JWT Claims
调试登录问题时，最常看的字段包括：
exp：过期时间，通常是 Unix 时间戳。iat：签发时间。nbf：在这个时间之前不可用。iss：签发方。aud：Token 面向的系统或客户端。sub：主体，常见为用户 ID。
如果 Token 明明存在却无法访问接口，先检查 exp 是否已经过期，再看 iss 和 aud 是否和后端预期一致。
解码和验证不是一回事
把 JWT 解码出来，只能说明它的前两段可以被解析成 JSON。它不能说明 Token 一定可信，也不能说明签名有效。
真正的验证需要服务端或后端库使用正确的密钥、算法、issuer、audience 和过期时间规则来检查。浏览器里的解码器适合帮助你看清内容，但最终有效性必须由实际鉴权系统判断。
常见安全误区
第一，不要把敏感数据放进 Payload。任何拿到 Token 的人都可以读取 Payload。
第二，不要使用过长的访问 Token 有效期。短期 access token 搭配 refresh token 更容易控制风险。
第三，不要忽略 exp。没有过期时间的 Token 一旦泄漏，风险会持续很久。
第四，不要把真实用户 Token 粘贴到不可信的网站、聊天记录、工单截图或日志里。即使只想看 Payload，也应该先确认工具是否本地处理，或者使用脱敏测试 Token。
第五，不要只信任前端判断。前端可以展示“已过期”或“格式错误”，但服务端仍然必须做最终鉴权。
调试 JWT 的安全流程
- 使用测试 Token 或已脱敏 Token。
- 解码 Header 和 Payload，确认字段是否存在。
- 检查
exp、iat、iss、aud、sub。 - 对照后端配置检查算法和密钥来源。
- 用实际后端验证结果作为最终结论。
如果你只是想知道 Token 为什么过期、为什么用户 ID 不对、或者为什么前端拿到的 audience 不一致，解码器通常足够定位第一层问题。
FAQ
JWT 解码需要密钥吗？
不需要。Header 和 Payload 可以直接解码。验证 Signature 才需要密钥、公钥或服务端配置。
JWT Payload 会被别人看到吗？
会。任何拿到 Token 的人都能读取 Payload，所以不要把密码、API Key、支付信息或隐私数据放进去。
在线 JWT 解码器安全吗？
取决于工具是否可信、是否本地处理，以及你粘贴的 Token 是否真实有效。BaseToolbox 在浏览器本地解码 JWT，但真实 Token 仍然应该按敏感凭证处理。