哈希、ID与随机数

查看 JWT 内容和到期时间，能知道什么？

使用工具

API 返回 401 时容易怀疑过期，但 JWT 内写着未来时间，并不能证明服务器判断错误。期限只是条件之一，签名、签发者与接收方也需要验证。这里用虚构令牌理解时间，不需要把真实认证信息贴进示例或咨询内容。

将下列字符串输入 JWT 解码。两个点分出 Header、Payload、Signature。这是 alg 为 none、签名为空的演示，不能用于登录。工具读取 Base64url 编码的 JSON，但能解析不代表可信。

无签名的虚构演示 JWT

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZW1vLXVzZXIiLCJpYXQiOjE3MDQwNjcyMDAsIm5iZiI6MTcwNDA2NzIwMCwiZXhwIjoxNzA0MDcwODAwfQ.

真实 JWT 可能含用户标识和权限。Base64url 不是加密，因此有签名也能读 Payload。读取内容与修改后仍通过认证是不同能力；签名验证与后者有关，而本解码页面不执行验证。

示例的 iat 和 nbf 是 1704067200，即 UTC 2024-01-01 00:00:00；exp 是 1704070800，即一小时后。iat 表示签发，nbf 表示不得早于的界限，exp 表示到期。有签发时间不代表所有令牌都有效一小时，这只是示例设置。

本例的 UTC 时间

iat = nbf = 2024-01-01T00:00:00Z
exp       = 2024-01-01T01:00:00Z

JWT NumericDate 以 Unix 秒为基础，直接将 Date.now() 的毫秒填入 exp 会改变含义。应确认生成方单位，再明确按秒转换，而非只凭位数修正。日期字符串不等于数值 Claim，本页面只对数值 Claim 做时间解析。

工具以设备当前时间提供过去或未来的参考，等于 exp 时归入已到期一侧。但它不知道服务器时钟、允许偏差或认证库设置。设备慢时，页面显示未来也可能已经超过服务器期限。

本地还是今天并不足以判断期限：UTC 01:00 与日本时间 10:00 是同一瞬间，换显示时区不会延长有效期。报告时附 UTC 或偏移，并区分浏览器观察与服务器日志；本工具不会查询服务器时钟。

修改 exp 后重新编码，可以让解码器显示未来，但签名 JWT 的被签内容变了，原签名就不再匹配。认证需要正确验证，解码成功和日期在未来都不等于认证成功，未验证提示正是为了区分两者。

显示 iss、aud 并不证明真实签发者或当前 API 就是接收方，alg 也只是输入数据而非可信配置。工具不获取外部密钥或联系认证服务器，下一步应检查验证端设置和日志，并尽量只分享必要标识与时间，不分享完整凭据。

此页面处理三部分 JWT，不解密五部分 JWE，也不支持服务自定义的不透明令牌。删分隔符或不断删字符直到不报错，就不再是在检查原信息。先检查复制范围、引号及 Authorization 的 Bearer 前缀，仅使用令牌本体。

最后记录 exp 的 UTC 时间、与设备时钟的关系，以及本页面未验证签名。缺少 Claim 时不要编造期限。即使不自动保存，屏幕共享、截图和剪贴板仍可能泄露凭据；先用虚构例子练习，真实数据按组织规则处理。

Payload 的 role、userId 看似权威，但画面只是读取声明，不确认发行者、受众、签名或当前权限。exp 在未来也不能替代这些检查。解码值可作调试线索，不能作为放行依据。

先确认失败请求实际用了哪个令牌。粘另一画面取到的未来 exp 令牌，不能否定失败请求过期。应统一令牌和客户端、服务端时刻。检查真实凭据时也注意共享屏幕和剪贴板暴露，公开问题报告用脱敏例子。

结论应限于此设备看来 exp 已过、nbf 尚未来到、无法解析三段等事实。不要称有效 JWT，以免暗示已验证。修改时间使 Payload 可读，不是修复原签名令牌，也不证明认证会接受。