JWT 过期检查：exp、nbf 与时钟偏差

exp 与 nbf 都是 Unix 秒级时间戳。检查逻辑很简单：当前时间超过 exp 即过期，早于 nbf 即尚未生效。真正需要设计的是「容忍多少时钟偏差」——两台服务器差几秒是常态。

三个时间声明

• exp（expiration time）：到这个时间之后 Token 不可用。
• nbf（not before）：到这个时间之前 Token 不可用。
• iat（issued at）：签发时间，用于判断 Token 年龄，不参与有效性判定。

三者都是 Unix 秒。写成毫秒（13 位）会让 exp 变成几万年以后，检查永远通过——这类 bug 不会报错，只会让 Token 永不过期。

为什么需要时钟偏差

签发服务器与验证服务器的时钟不可能完全一致。NTP 正常时误差在毫秒级，但虚拟机暂停、容器迁移、时钟漂移都可能造成几秒到几十秒的偏差。

没有偏差容忍时会出现：Token 刚签发就被判「尚未生效」（nbf 在未来几秒），或者刚过期就被别的节点判「还有效」。允许 30–60 秒偏差是常见做法。

偏差不能设太大：设成 300 秒等于让过期的 Token 多活五分钟，这是实打实的攻击窗口。

没有 exp 会怎样

规范里 exp 是可选的。没有 exp 的 Token 永不过期——一旦泄露，攻击者可以一直用到密钥轮换。

这个工具遇到没有 exp 的 Token 会明确提示「该 Token 永不过期」，而不是当作通过。这个提示很重要：它把一个容易被忽略的配置问题摆到明面上。

过期不等于失效

JWT 是无状态的：服务端不保存 Token，也没法「主动作废」某一个。exp 到了只是客户端与服务端都拒绝使用它。

需要立即失效（比如用户改密码、踢下线）时，得靠额外机制：短有效期 + 刷新令牌、维护一个吊销列表（jti 黑名单）、或把会话状态放回服务端。这是 JWT 的固有限制，不是实现问题。