关于 JWT 解码器
这款免费的 JWT 解码器读取 JSON Web Token，将其头部和载荷显示为格式化的 JSON，并把签发时间和过期时间转换成易读的日期。
解码在您的浏览器中完成 — 您的令牌绝不会被上传。这不是小事：JWT 通常是一份有效的凭证，把它粘贴到会把它发往别处的网站，等于交出它所携带的全部访问权限。
本工具解码令牌，但不验证签名 — 下文说明这一区别为何重要。
令牌的三个部分
一个 JWT 是用点分隔的三段 Base64url：
xxxxx.yyyyy.zzzzz
头部 — 说明令牌由哪种算法签名，以及它是什么类型。通常是两个字段：alg 和 typ。
载荷 — 也就是声明（claims）。令牌关于谁、由谁签发、何时过期，以及应用放进去的其他内容：用户 ID、邮箱、角色、权限、租户。
签名 — 对前两部分做的密码学校验，用一个密钥或私钥生成。它证明令牌自签发以来没有被改动。
必须理解的关键是：前两部分并未加密。 它们只是被编码了，任何人都能读取。把令牌粘贴到本页面，内容立刻显现。Base64url 是让数据能安全放进 URL 或请求头的方法，而不是隐藏数据的方法。
这对令牌里该放什么意味着什么
既然载荷对任何持有令牌的人都是公开的，规则就直接得出：绝不要把任何机密放进 JWT。
不该出现在载荷中的内容：密码、API 密钥、信用卡信息、身份证件号码、医疗信息，以及任何受隐私法规保护的数据。这些内容用户本人能读到，任何记录该请求的系统能读到，任何拿到令牌的人也能读到。
该放的内容：用户 ID、角色、过期时间、签发者、受众 — 这些标识和声明本就是给接收系统看的。
签名保护的是完整性，不是机密性。它保证没人改动过令牌，却完全无法阻止别人读取它。
解码不等于验证
这个区别会造成真实的安全漏洞，因此值得说清楚。
解码把 Base64url 拆开，向您展示 JSON。它不需要任何密钥，任何人都能做，而且丝毫不能证明令牌是否真实。
验证用密钥或公钥重新计算签名，并检查是否吻合。只有这一步才能告诉您：令牌确实由它所声称的一方签发，且未被篡改。
一个令牌可以完美解码，同时又是彻头彻尾的伪造品。任何人都能造出一个写着 "role": "admin" 的 JWT，它在这里会漂亮地显示出来 — 因为这里发生的全部就是显示。
本工具刻意不做验证，这是安全的选择：验证需要签名密钥，而把签名密钥粘贴到网页里，远比粘贴一个令牌危险得多。验证应当在您自己的服务器上、用您的密钥、通过正规的库来完成。
这一错误的历史版本是 alg: none 攻击。早期的 JWT 库会听信一个声称未使用任何算法的头部，于是不加验证地接受令牌。攻击者只需修改载荷、把 alg 设为 none，便可长驱直入。现代库会拒绝这种做法，但这正是您应当始终锁定期望的算法、而不是听信头部的原因。
读懂标准声明
载荷中大多数简短的字段名都是含义固定的注册声明：
- exp — 过期时间。此后令牌应被拒绝。
- iat — issued at，签发时间。它是何时创建的。
- nbf — not before，生效时间。在此之前令牌无效。
- sub — 主体。通常是用户 ID。
- iss — 签发者。是谁创建了该令牌。
- aud — 受众。它是给哪个服务用的。
- jti — 令牌 ID，用于吊销列表。
exp、iat 和 nbf 都是 Unix 时间戳 — 自 1970 年 1 月 1 日起的秒数 — 所以它们看起来像一串毫无意义的十位数字。本工具会把它们转换成易读的日期，这通常是回答把您带到这里的那个问题最快的办法：*这个令牌过期了吗？*
使用方法
- 粘贴您的 JWT（xxxxx.yyyyy.zzzzz 形式的字符串）
- 在下方查看解码后的头部和载荷
- 需要时可复制其中任意一部分
值得注意
- 把令牌当作密码对待。 只要它仍然有效，持有者就能以该用户的身份行事。不要把有效令牌粘贴进会上传它们的工具，也不要发到工单或聊天里。
- JWT 难以吊销。 它们在过期前一直有效，所以被窃取的令牌在那之前都能用，除非您维护一份阻止列表。这正是短过期时间重要的原因。
- Bearer 不是令牌的一部分。 解码前请从 Authorization 请求头中去掉这个前缀。
- Base64url 不是标准 Base64。 它用 - 和 _ 代替 + 和 /，通常还去掉 = 填充，所以 JWT 的某一段在普通 Base64 解码器里可能失败。
- 时钟偏差会造成令人困惑的失败。 一个在您看来有效的令牌，可能被时钟相差一两分钟的服务器拒绝。
- JWT 不是会话。 它自带声明，因此更改用户角色要到令牌过期后才会生效。
常见问题
JWT 是加密的吗？
不是。头部和载荷采用 Base64url 编码，这让它们能安全地放进 URL 或 HTTP 请求头，却完全没有隐藏作用。正如本页所展示的，任何持有令牌的人都能读到其中的每一项声明。签名保护令牌不被修改，而不是不被读取。
这个工具会验证签名吗？
不会，而且是刻意如此。验证需要签名密钥或公钥，而把签名密钥粘贴到网页里，要比粘贴令牌危险得多。验证应当在您的服务器上使用正规的库完成。本工具负责解码并展示内容，这正是调试时您需要的。
在这里粘贴我的令牌安全吗？
在这里是安全的 — 解码完全在您的浏览器中进行，没有任何数据被传输，您甚至可以断开网络，它依然可用。不过，对工具总体上仍要保持警惕。一个有效的 JWT 就是一份能用的凭证，把它发送到服务器的网站，等于刚刚获得了它所授予的全部权限。
我怎么知道令牌是否过期了？
查看 exp 声明，它是以秒为单位的 Unix 时间戳。本工具会把它转换为易读日期，并直接告诉您该时刻是否已过。如果令牌在您看来有效却被服务器拒绝，请检查时钟偏差 — 机器之间相差一两分钟就足够了。
sub、iss、aud 和 iat 是什么意思？
它们都是含义标准的注册声明：sub 是主体，通常为用户 ID；iss 是创建令牌的签发者；aud 是预期受众，即哪个服务应当接受它；iat 是签发时间。与 exp 和 nbf 一起，涵盖了谁、在哪里、在何时。
为什么我的 JWT 在普通 Base64 解码器里失败？
因为 JWT 使用 Base64url，这是一种把 + 换成 -、把 / 换成 _，并通常去掉 = 填充的变体。这些替换是为了让取值能安全地放在 URL 中。把这些字符换回去，就能在标准 Base64 工具里解码了。
我可以编辑 JWT 的载荷吗？
您可以修改文本，但任何实现正确的服务器都会拒绝这个结果，因为签名不再与改动后的内容吻合。签名的用途正在于此。令牌应由为其签名的服务重新签发，而不是手工编辑。
相关工具
- Base64 编码 / 解码 — 这三段内容所采用的编码方式
- JSON 格式化 — 整理并查看解码后的载荷
- 哈希生成器 — 签名底层所用的哈希函数
