JWT 认证深度解析：优势、缺陷与设计边界

在 Web 开发和系统架构设计中，身份验证（Authentication）是系统的基石。传统的基于 Session 或随机 Key 的 Token 机制与现代的 JWT（JSON Web Token）是两种最主流的方案。

然而，在面试和实际开发中，我们往往容易只看到 JWT 的便捷，而忽略了它的适用边界。本文将从无状态验证、存储开销、时效控制等维度，深度剖析 JWT 的优势与致命缺陷。

1. JWT 的底层原理：无状态的“自包含门票”

JWT 的核心理念是：用计算时间换取存储空间。

JWT 是一种**自包含（Self-contained）**的 Token。它将用户信息、过期时间等数据经过 Base64 编码后，存放在 Payload 中，并使用签名（Signature）确保数据防篡改。

生成：后端验证用户凭证成功后，用私钥对 Payload 进行签名，生成 JWT 字符串发送给客户端。
校验：客户端每次请求携带该 JWT，后端不需要查询任何数据库或缓存（如 Redis），只需用相同的密钥对签名进行“反算/校验”，就能知道该 Token 是否有效、以及它是哪个用户。

用户量越大，JWT 的无状态优势越明显：
如果有 10 万、100 万用户同时在线，传统 Session 方式会在 Redis 中产生海量的 Token -> UserInfo 键值对，占用极大的内存空间；而使用 JWT，后端的存储开销为 0。

对比之下，传统的 Token 机制更像是一把“钥匙”。

原理：后端随机生成一个无意义的 Key（例如 UUID/随机字符串），作为 Token 发给客户端，同时将这个 Key 和用户身份（User ID）的映射关系存入内存或 Redis 中。
校验：每次请求到来，后端必须拿着这把“钥匙”去“保险箱”（Redis/数据库）里查一下对应的用户是谁，如果查不到或已过期，则拒绝请求。

无状态是 JWT 的最大优点，也是它的致命缺陷。 因为后端不保存 Token 的状态，导致 JWT 就像是一张盖了章的实体门票，只要在有效期内，谁拿着都能进，后端无法单方面强制废弃它。

这在实际业务中会引发几个非常棘手的痛点：

如果用户发现自己的密码泄露，立刻修改了密码，后端虽然更新了数据库并颁发了新的 JWT，但黑客手里的旧 JWT 在过期时间（Exp）到来之前，依然可以正常请求系统。后端由于没有存储 Token 状态，根本无法得知这个 Token 已经被“作废”了。

当用户点击“退出登录”时，前端虽然把本地的 JWT 删除了，但只要这个 JWT 还没有过期，一旦它在此前被攻击者截获，攻击者在过期前仍可合法请求后端。

如果管理员把某个违规用户封禁了，或者修改了该用户的角色权限，但在该用户持有的 JWT 过期之前，他依然能用旧的 JWT 访问那些他本来已经失去权限的接口。

为了解决上述缺陷，业界通常有以下折中方案：

将需要提前失效的 JWT 的唯一标识（如 jti）存入 Redis，并设置与其过期时间相同的 TTL。每次接口请求时，后端先去 Redis 查一下该 Token 是不是在黑名单里。

在进行架构设计时，必须搞清楚技术的边界：

选择 JWT 的场景：适合短时效、一次性、无状态的单向授权场景，如单点登录（SSO）的跨域跳转、邮箱激活链接验证、临时文件下载凭证等。
选择传统 Session/Token 的场景：适合常规的、对控权安全要求极高的系统 Web 登录。能随时封禁用户、随时强制下线，才是最安全的防御策略。