← 返回工具箱

JWT / NUMERICDATE

JWT exp / nbf / iat 时间检查器

以当前时刻或自定义时刻检查 JWT 的过期、生效和签发时间。JWT NumericDate 的单位是从 Unix Epoch 起算的秒，不是常见 JavaScript 毫秒时间戳。

exp

当前时刻必须早于 exp。到达 exp 的那一刻就已经过期，可按策略加入少量 leeway。

nbf

当前时刻在 nbf 之前时不可接受。leeway 只用于容忍小幅时钟偏差。

iat

表示签发时刻，本身不是自动拒绝规则；未来 iat 或异常长生命周期应复核。

检查时刻与容差

COMMON TIME BUGS

最常见的不是过期，而是单位和口径错了

把毫秒写进 exp

Date.now() 返回毫秒，JWT NumericDate 使用秒。应先除以 1000，再按策略取整。

把 iat 当成自动有效

iat 只记录签发时刻。是否限制最大年龄、是否拒绝未来 iat，需要由具体应用明确规定。

只看 exp 不验签

攻击者可以直接改写 Payload 中的 exp。必须先验签，再用可信服务器时间检查 Claims。

RELATED TOOLS

接着处理

查看全部工具 →
JWT 解码器查看 Header、Payload 与标准 Claims。JWT 签名 / 验证固定预期 HMAC 算法并验证签名。Unix 时间戳在秒、毫秒、微秒、纳秒与日期间转换。跨时区时间比较不同城市的本地时间。

USE & REVIEW

JWT exp / nbf / iat 时间检查器常见问题

查看全部工具指南 →

JWT 的 exp 在等于当前时刻时算过期吗？

算。规范要求当前时间必须早于 exp，因此参考时刻到达 exp 就不能再接受。页面使用“reference >= exp + leeway”判断过期；leeway 为 0 时不会额外宽限。不同库的取整方式可能影响亚秒边界，生产端应统一时钟、单位和测试案例。

Leeway / Clock Skew 应该设置多大？

它只用于容忍分布式服务器之间很小的时钟偏差，常见策略是数秒到一两分钟，具体取决于基础设施。不要用几小时或几天的 leeway 掩盖错误过期时间，否则实际有效期会被偷偷拉长。签发方和验证方还应使用可靠时间同步，并记录拒绝原因。

iat 晚于当前时间，Token 就一定无效吗？

不一定。iat 表示签发时刻，规范没有规定所有实现必须因未来 iat 自动拒绝。它可能来自时钟偏差，也可能是错误或伪造数据。页面把未来 iat 标为警告；若业务要限制最大 Token 年龄或拒绝未来签发，应在服务端明确策略，并在验签后执行。

为什么 13 位 exp 会被提示像毫秒时间戳？

当前 Unix 毫秒通常是 13 位，而 JWT NumericDate 使用秒，通常约 10 位。把 Date.now() 原样写进 exp 会把过期时间推到极远未来，甚至超出日期库范围。页面不会擅自除以 1000 修正，因为远期秒数也可能是有意输入，只会提示你核对单位。

时间条件通过，为什么页面仍写着“未验签”？

因为攻击者可以直接改写未验证 Payload 里的 exp、nbf 和 iat。时间检查只回答这些数字相对参考时刻是否满足条件，不能证明它们是谁写的。正确顺序是先按固定算法验证签名，再检查 issuer、audience、时间、权限和撤销状态。

JWT 时间检查会上传 Token 吗？

不会。结构解析、参考时间比较、leeway、生命周期和 JSON 报告都在当前浏览器完成。自定义时刻按浏览器本地时区解释，报告则使用 ISO UTC 保存参考时刻。生产 Token 仍应优先脱敏，因为下载报告、剪贴板和截图可能被另行保存或分享。