工作原理
JWT 的形式是 header.payload.signature,前两段是 Base64URL 编码的 JSON。头部用 alg 声明签名算法,用 kid 标识密钥;载荷承载声明,本质上就是一组 JSON 键值对。签名是对 header.payload 这个字面字符串——包含编码后的确切字节——使用头部所指算法和颁发方持有的密钥计算出来的。解析前两段不需要任何密钥,这也是常见困惑的来源:Base64URL 是编码,不是保护。
注册声明有固定含义:iss 标识颁发方,aud 标识预期接收方,sub 标识主体,exp 是以 Unix 时间戳表示的过期时刻,nbf 是生效时刻,iat 是签发时刻,jti 是用于吊销列表的唯一标识。校验不只是解码:服务端必须确认签名通过、当前时间位于 nbf 与 exp 之间、iss 与自身身份一致、aud 包含自己。一个能够正常解析且尚未过期的 token 仍可能因为其他任何一条被拒绝。
算法分为两族。HS256、HS384、HS512 属于 HMAC:同一把密钥既签名又验签,这在单一后端同时掌握两端时没问题,但意味着任何能验签的一方也能伪造。RS256 与 ES256 是非对称的:颁发方用私钥签名,各服务用公钥验签,因此被攻破的验签方无法凭空签发 token。none 算法意味着完全不签名,而 JWT 的经典漏洞就是某库从 token 头部读取 alg 并接受 none,或是在服务端其实用 RSA 公钥验签时接受了 HS256。
验签之所以重要,是因为单独解析出的载荷不能证明任何事情。任何人都能伪造一个带管理员角色和未来过期时间的 token,只有签名把这些声明绑定到颁发方。本工具在本地重算签名——HS* 走 Web Crypto 的 HMAC,RS* 走 RSA-PSS 或 RSASSA-PKCS1-v1_5——并逐字节比对,从而把生产环境的“签名无效”定位到密钥错误、算法错误或 token 被截断,而不用靠猜。
常见应用场景
- 解析从 Authorization 请求头里复制出的 token,确认它携带的是哪个租户或角色。
- 把 exp 时间戳读成日期,判断“令牌过期”报错是否属实。
- 用共享密钥验证 Webhook 签名,确认自己的 HMAC 代码写对了。
- 检查身份提供方发送的 audience 是否确实是 API 所期望的。
- 比对 token 头部的 alg 与 kid 和服务端已配置的密钥,追踪 401 的成因。
- 在把 token 写进日志前确认其中不含敏感个人信息。
最后更新: 2026-10-14