JWT 解析指南：看懂 header、payload 与有效期

把 token 粘进来就能看到 header 和 payload，但要记住一件事：解码只说明内容长什么样，不说明它可信。要判断 token 是否合法，必须在服务端验证签名。

什么时候需要看 JWT 的内容

接口返回 401，你想确认到底是过期了、受众对不上、还是签名验证失败——这时候看 exp、aud、iss 最快。对接第三方单点登录时，对方给的 token 里究竟带了哪些 claim，也常常只能解开看。

还有一种情况是排查「明明登录了却没有权限」：角色写在哪个字段、是不是嵌套在 user.roles 里、网关有没有把 claim 改名。这些都不是签名问题，读 payload 就能定位。

看懂三个部分和几个时间字段

JWT 由 header.payload.signature 三段组成，用点号分隔。前两段是 Base64URL 编码的 JSON，第三段是签名。注意是 Base64URL 不是 Base64：它把 + 换成 -、/ 换成 _，并去掉末尾的 =，所以有些 token 丢给普通 Base64 解码器会报错。

exp（过期）、iat（签发）、nbf（生效）都是 NumericDate，即从 1970-01-01 UTC 起算的秒数，不是毫秒，也不是本地时间。10 位数才对；如果是 13 位，说明对方塞了毫秒，按秒解读会得到几万年后的日期。

exp 是「不早于此刻失效」的上限，判断时留 30–60 秒时钟偏差
payload 只是 Base64URL，谁拿到 token 都能读，不要放身份证号、手机号、密钥
只有两段或签名段为空，说明这不是完整的 JWS

局限：不验签就等于没验证

解码器不会告诉你 token 有没有被改过。攻击面恰恰在这里：alg 设为 none 的老漏洞、把 RS256 换成 HS256 并用公钥当 HMAC 密钥的混淆攻击、通过 jku、x5u、kid 让服务端去加载攻击者提供的密钥。这些都不是解码能发现的。

正确的做法是服务端用成熟库验证，并显式指定允许的算法白名单，而不是信任 header 里的 alg。前端读 exp 来判断「要不要提前刷新」是够用的；但任何涉及权限的决策，都必须由验签后的服务端来做。

常见问题

JWT 解析安全吗？把 token 粘到网页里会泄露吗？

这个工具的解析全部在浏览器里完成，token 不会发到服务器。但通用建议仍然成立：生产环境的 token 等同于密码，只在必要时粘贴，用完关掉页面；不要贴到来源不明、需要联网请求的解析站点。

为什么提示不是合法的 JWT？

常见原因有三个：复制时漏了最后一段、token 前面还带着 Bearer 前缀、以及这其实是 JWE（加密的 JWT，五段）而不是 JWS。另外 Base64URL 去掉了补位的等号，某些解码器会因此报错。

能从这个工具看出 token 有没有被篡改吗？

不能。解码不校验签名，改了 payload 再重新 Base64URL 编码，页面照样显示得出来。要判断真伪只有一条路：用密钥在服务端验证签名，并核对 exp、aud、iss。