开发
解析 JWT
JWT 只是编码，不是加密——任何拿到它的人都能读出里面的声明。这个工具做的就是这件事，另外还会告诉你这个 token 是不是已经过期了。
HEADER
—
PAYLOAD
—
怎么用
- 粘贴完整 token，两个点都要带上。
- Header 和 payload 会随输入实时解码。
- exp / iat / nbf 会换算成可读的 UTC 时间。
- 本工具不校验签名，原因见下方说明。
三段各自是干什么的
Header、payload、签名，用点分开。header 声明签名算法，payload 携带声明，签名把前两者和一个密钥绑在一起。只有签名提供安全性——前两段是 Base64url，是编码不是加密。你在这里看到的每一条声明，任何截获了这个 token 的人都能读到。
真正被利用的那几个错误
接受 alg: none，攻击者就能剥掉签名让 token 通过。信任 header 里写的算法、而不是服务器期望的算法，会招来算法混淆攻击——把 RSA 公钥当成 HMAC 的密钥来用。而先读声明再验签，等于把未验证的内容当成事实。顺序必须是先验证，再读取。
排查 401 之前先看一眼
多数的鉴权失败，在跑任何代码之前就能从载荷里看出来。看三个字段：exp 对比当前时间；有 nbf 就看它（令牌还没生效——服务器时钟走快的典型症状）；以及当发给 A 服务的令牌被拿去访问 B 服务时，看 aud 和 iss。
要记住：能解开不等于可信。让令牌可信的是签名，而本页不验证签名——这是设计如此，验证需要密钥。这里读到的每一条都只是声明，不是事实。
常见问题
会校验签名吗？
不会。校验需要密钥或公钥，在浏览器里做等于把密钥交给一个网页。签名校验请用服务端库完成；这个工具只用于调试时读声明。
为什么 payload 解出来是乱码？
多半是 token 被截断了，或者漏掉了最后一段。一个 JWT 由两个点分成三段，不是这个形状就不是完整 token。
贴生产环境的 token 安全吗？
解码完全在这个标签页里完成，token 不会被发送。但它本质上等同密码——泄露的 token 在过期前就是泄露的会话。
exp、iat、nbf 分别是什么？
exp 是过期时间，iat 是签发时间，nbf 是最早可被接受的时间。三者都是 UTC 的 Unix 秒数。
这个页面能验证签名吗？
不能，也不该能。验证需要签名密钥或公钥，它们不应该出现在任何浏览器页面里。
为什么令牌比它携带的数据长那么多？
头部、载荷和签名各自单独做 Base64URL 编码，再用点号连起来。Base64 本身膨胀约三分之一，而签名长度固定，与载荷大小无关。