JWT 解码

JSON Web Token 看着像乱码，其实大部分是可读的：三个部分里有两个只是经 base64 编码的 JSON。这个解码器把它们打开，让你看到令牌发给谁、声明了什么，以及确切何时过期——通常是在排查某个请求为何被拒的时候。如果你有密钥，它还能校验 HMAC 签名，从而确认令牌真的出自你以为的那个系统。令牌是活的凭据，所以它在页面内运行这件事很要紧：令牌和密钥都不会被发送到任何地方。

如何解码 JWT

粘贴令牌。三段以点分隔的内容全都要，照它在请求头或 Cookie 里的样子原样贴上。
并排阅读头部和载荷。头部写明签名算法，载荷装着各项声明。
看日期面板：exp、iat 和 nbf 会显示为真实时间，已过期的令牌会被标出。
要确认签名，把签发用的密钥粘进来并点校验。此功能适用于 HS256、HS384 和 HS512。

关于 JSON Web Token 的常见问题

把真实令牌粘在这里安全吗？

比多数地方安全，因为解码发生在你的浏览器里，也不会有任何东西经过网络。但仍要把令牌当成它本来的身份——凭据：任何看到你屏幕或剪贴板的人就等于拿到了它；如果那是一个活的会话令牌，它到过期前一直有效。

载荷是加密的吗？

不是，这一点常让人意外。头部和载荷只是经过 base64 编码——任何持有令牌的人都能不用密钥读出来。签名阻止内容被改动，而不是被读取。永远不要把机密放进 JWT 的载荷。

为什么只能校验 HS256 这一类？

因为它们用共享密钥签名，而你可以把密钥粘进来。RS256、ES256 等则用私钥签名、用配对的公钥校验，而那个公钥通常得从签发方的 JWKS 端点取回——那意味着要发请求，而本工具不发请求。

签名对不上，是哪里出了问题？

最常见的是这个密钥并非签名所用的那个，或者粘贴时带进了多余的空格或换行。也可能令牌实际用的算法与头部声称的不同，或者它被人改动过——而后者正是校验存在的意义。

exp、iat 和 nbf 是什么意思？

它们是标准的时间声明，都是以秒为单位的 Unix 时间戳。exp 是令牌失效的时刻，iat 是它签发的时刻，nbf 是最早可以使用它的时刻。本页把三者都显示为普通日期，并对 exp 已过的令牌加上标记。