JWT 认证鉴权从入门到高并发踩坑全景手册

1. 重新认识 JWT：无状态带来的利与弊#

在微服务与前后端分离架构中，JSON Web Token (JWT) 几乎成为了身份鉴权的标准代名词。它的最大优势在于：服务端无状态。 网关校验签名合法后即可直接信任其中的用户身份，无需每次请求都跨网络去中心化 Redis 或数据库查询 Session。

然而，“无状态”也是一把双刃剑，它带来了一系列安全与业务上的致命挑战。

---

2. 开发者最常踩的四大安全陷阱#

陷阱一：误将敏感数据存入 Payload#

JWT 由三部分组成：Header.Payload.Signature。 很多初学者误以为 JWT 是“加密”的，甚至把用户密码、手机号直接放进 Payload 中。 实际上，Payload 仅仅是做了简单的 Base64URL 编码！ 任何拿到 Token 的人都可以使用站内的 [JWT Token 解析工具](/tools/jwt) 一秒还原出明文数据。

陷阱二：Token 有效期设置过长#

如果为了省事将 JWT 的过期时间（exp）设置为 30 天，一旦用户的 Token 遭遇网络中间人劫持或客户端 XSS 盗取，攻击者将在整整 30 天内拥有完全合法的账户控制权，服务端甚至无法单方面使其失效。

---

3. 最佳实践：Access Token + Refresh Token 双令牌架构#

为了兼顾安全性与用户登录体验，现代工程标准的做法是采用双令牌体系：

Access Token（访问令牌）：

* 寿命短：通常设置为 15 分钟 ~ 2 小时； * 随业务请求携带在 Header (Authorization: Bearer ) 中；

Refresh Token（刷新令牌）：

* 寿命长：通常设置为 7 天 ~ 30 天； * 存放在 HttpOnly Cookie 或本地安全存储中，并且在服务端 Redis 记录其 Hash 指纹； * 当前端发现 API 返回 401 且 Access Token 过期时，在拦截器中无感调用 /api/auth/refresh 换取新的 Access Token。

---

4. 服务端如何实现“主动注销 / 强制下线”？#

既然 JWT 是无状态的，如果用户修改了密码或在管理后台点击了“退出登录”，如何让未过期的 Token 立即作废？

主流工业级解法：Redis 动态黑名单（Blacklist）机制 当用户主动退出时，将当前 Token 的唯一标识（jti）或整个 Token 写入 Redis：

bash
# 写入 Redis 黑名单，过期时间设置为该 Token 距离失效的剩余秒数
SETEX blacklist:jwt:<jti> <remaining_seconds> "revoked"

鉴权中间件在校验 JWT 签名有效后，快速判断 Redis 中是否存在该 key，若存在则直接拦截并返回 401。通过将 TTL 限制在剩余有效期内，Redis 占用的内存空间极小且能自动清理。