JWT Decode 和 Verify 到底差在哪

JWT 很适合粘贴到解码工具里排查问题。真正危险的是，把解码出来的 JSON 当成“可信证明”。

Decode 只回答一个问题：这个 Token 声称了什么。Verify 回答的是另一个问题：这个 Token 是否由可信发行方按预期算法签名，并且确实发给当前应用使用。

Decode 能看到什么

解码可以检查 Token 结构：

• Header 里的 alg、typ、kid。
• Payload 里的 sub、iss、aud、exp、iat、nbf。
• Header 和 payload 是否是合法的 Base64URL JSON。
• 时间声明是否已过期、来自未来，或受时钟偏差影响。

这足够解决很多调试问题。比如请求返回 401 时，可以先看 Token 是否过期、audience 是否不对、是否缺少后端需要的声明。

Decode 不能证明什么

解码后的声明在验证前只是文本。任何人都可以修改 payload，再重新编码成一个看起来像 Token 的字符串。

Verify 至少需要检查：

• 使用正确密钥或公钥验证签名。
• 算法是否是应用预期的算法。
• issuer 是否是可信发行方。
• audience 或 client ID 是否匹配当前服务。
• exp、nbf 等时间窗口。
• 应用自己的授权规则。

这些工作应该由后端、API 网关、认证中间件或可信认证库完成。

实用排查顺序

遇到 JWT 问题时，可以先做可见性检查：

1. 用 JWT 解码器 在本地解码 Token。
2. 确认 Token 有三个片段。
3. 查看 iss、aud、sub、exp、iat、nbf。
4. 如果时间看起来异常，用 时间戳转换器 转成人类可读时间。
5. 再查看后端日志里的具体验证错误。

之后再调整签名密钥、身份提供方配置或中间件设置。

常见错误

最常见的错误，是应用代码只解码 Token 就直接信任声明。另一个常见错误，是验证了签名，却没有验证 issuer 或 audience，导致其它系统签发的有效 Token 被错误接受。

时钟偏差也很常见。身份提供方认为 Token 已经有效，但 API 服务器时间落后，就可能出现尚未生效。可以设置小范围 leeway，但必须明确。

安全的理解方式

Decode 用来看清内容。Verify 用来建立信任。授权规则决定能不能访问资源。

这三步分开看，JWT 调试会清楚很多。