JWT 不是无状态银弹：Session、Redis 与 WebSocket 分布式鉴权的工程取舍

技术争论里最容易吵起来的，往往不是某个方案能不能用，而是大家拿着不同的前提在争同一个词。

比如一句“把 token 存到 Redis，登录一次变一次，旧 token 请求接口就作废”，有人会立刻说：这不就是 Session 吗？JWT 的优势全被你干没了。另一边也会反驳：我就是要单点登录、踢人、封号、改密后立即失效，不查 Redis 怎么保证？

真正的问题不在于“JWT 能不能存 Redis”，而在于你必须承认自己到底在做什么。

JWT + Redis 不是错误方案，但它已经不是纯无状态认证。它是以 JWT 作为票据格式，以 Redis 作为会话控制面的混合式鉴权。

这句话把争端基本就解开了。JWT 不是宗教，Session 也不是落后。无状态不是银弹，有状态也不等于低级。它们只是把系统复杂度放在了不同位置。

争论的核心：JWT 是票据，不是会话治理

如果你的系统只需要普通 API 鉴权，用户登录后拿一个短期 access_token，服务端只校验签名和过期时间，不关心旧 token 是否立刻失效，那么纯 JWT 很舒服。任意节点只要拿到密钥或公钥，就能独立完成校验，横向扩容也简单。

但如果你的系统要求一个账号只能同时登录一个设备，新登录后旧登录立刻失效，修改密码、封号、踢人必须实时生效，WebSocket 长连接还要能被服务端主动断开，那就不要再执着“纯无状态”了。你天然需要服务端状态。

这不是退步，而是需求本身决定的。

所谓工程判断，本质上就是承认代价，然后把代价放在最可控的位置。对于登录态这种安全边界，很多时候把状态放回服务端，反而比假装自己无状态更可靠。

实际项目里，这个分歧通常不是出现在登录接口刚写完的时候，而是出现在需求开始“长牙”以后。第一版只需要登录、带 token 访问接口、过期重新登录，看起来 JWT 非常漂亮；第二版产品说一个账号只能一个设备在线；第三版安全同学说改密后所有旧登录态必须立刻失效；第四版运营后台要支持封号、踢人、冻结高风险用户；第五版你又接入了 WebSocket，用户已经连上服务器，不会等下一次 HTTP 请求才暴露问题。

到这个阶段，继续坚持“服务端绝不保存状态”就不再是架构洁癖，而是在和需求作对。系统当然还能硬撑，比如把 access token 做得极短，靠频繁刷新缩小失效窗口；或者维护一张黑名单，所有请求先查 token 是否被吊销；或者在 JWT 里塞一个用户版本号，每次请求再去查版本是否一致。但只要你开始做这些事，本质上就已经承认：身份凭证之外，还需要一个服务端控制面。

所以这篇文章真正想讨论的不是 JWT 和 Session 谁赢谁输，而是一个更朴素的问题：当业务需要强控制时，状态应该放在哪里，怎么放，失败时怎么办。

“无状态认证”的核心是：服务端不保存每一个客户端的会话事实，每次请求都携带足够的信息，服务端通过签名、时间和声明完成判断。“有状态认证”的核心是：服务端保存会话事实，客户端只持有一个索引或票据，每次请求都要回到服务端状态存储里确认它是否仍然有效。

这两种模型的差异可以简单拆开：

争论的关键不是“谁更高级”，而是你到底要吞下哪一种复杂度。纯 JWT 把复杂度放在 token 生命周期上：过期前很难强制收回。有状态 Session 把复杂度放在集中存储上：每次请求都要依赖 Redis、DB 或 Session 服务。

这也是很多讨论容易误导人的地方。有人说“JWT 不用查库，所以性能好”，这句话只在纯本地验签的前提下成立；如果你每次都拿 jti 查 Redis，它就已经不是那个性能模型了。有人说“Session 不能分布式”，这句话也只在 Session 存单机内存时成立；如果 Session 本来就在 Redis 或专门的会话服务里，多节点并不是问题，真正的问题变成了集中依赖、容量、延迟和故障恢复。

这也是为什么真实工程里最常见的不是二选一，而是混合模型。

JWT 的全称是 JSON Web Token。它本质上是一种紧凑的、可签名的声明载体，常见结构是：

header.payload.signature

它的价值在于可以把 userId、sessionId、role、exp 等声明放进 token；服务端可以通过签名确认内容没有被篡改；多个服务只要共享密钥或公钥，就能独立完成基础校验。它非常适合 API、移动端、微服务内部身份传递。

但 JWT 并不自动等于无状态。只要你的验证逻辑变成这样：

1. 校验 JWT 签名
2. 校验 exp 是否过期
3. 拿 JWT 里的 sid / jti 去 Redis 查是否仍然有效
4. Redis 里存在并匹配才放行

那这个系统就已经引入了服务端状态。

这没有问题。问题只在于你不能一边每次请求都查 Redis，一边还宣称自己是纯无状态架构。准确的说法应该是：

我们使用 JWT 作为客户端凭证格式，但登录态有效性由 Redis 集中控制。

这句话才是工程语言。

JWT 还有一个经常被忽略的安全边界：它不是加密。普通签名 JWT 的 payload 可以被任何拿到 token 的人解码查看，所以不要往里面塞手机号、身份证号、密码、密钥、支付信息这类敏感数据。JWT 防篡改，不防读取。除非你使用的是 JWE 这类加密型 token，否则它只是“签名票据”，不是“保险箱”。

Session 也不是落后技术。很多人嫌 Session 老，是因为早期 Session 经常和单体应用、浏览器 Cookie、服务端内存绑定在一起。一旦上了多节点，内存 Session 就会遇到负载均衡、节点重启、会话丢失的问题。但这不是 Session 模型的问题，而是存储位置的问题。

在现代架构里，Session 完全可以放在 Redis：

session:{sid} = {
  userId: 10001,
  loginAt: 1710000000,
  expireAt: 1710007200,
  device: "ios",
  ip: "1.2.3.4"
}

客户端只拿一个 sid，服务端每次通过 sid 去 Redis 查真实会话。登出时删除 Session，踢人时删除 Session，封号时删除所有 Session，单端登录时只保留当前 Session，权限变化时更新服务端状态。它的控制力很强，代价也很直接：Redis 成了认证链路上的关键依赖。Redis 延迟、抖动、网络分区，都会影响认证稳定性。

这里也要说得准确一点：Session 不是“天然”解决所有问题，而是它把问题放在服务端以后，更容易用一致的方式解决。单端登录不是随便用了 Session 就自动出现，你仍然要设计 userId -> sid 的映射；改密后全部失效也不是魔法，你仍然要删除用户所有 session，或者递增用户版本号；权限实时生效也不是凭空发生，你仍然要决定权限是每次读取，还是写入 session 后通过事件刷新。Session 的优势不在于免设计，而在于它承认服务端有最终控制权。

所以，JWT 适合身份声明，Session 适合会话控制。真正复杂的系统，往往两个都要。

混合方案：短 JWT、可吊销 refresh token、Redis 会话控制面

对于“登录一次变一次，旧 token 立即废掉”的需求，我更推荐一个混合方案：

短生命周期 access token
+ 可轮换、可吊销的 refresh token
+ Redis 保存当前有效会话 sid / version

这里的关键不是“把完整 JWT 原文扔进 Redis”，而是把会话控制权放在 Redis。登录成功后生成一个 sid，JWT 里不要只放 userId，还要放会话标识和版本号：

{
  "sub": "10001",
  "sid": "s_8f3a9c2e",
  "ver": 12,
  "iat": 1710000000,
  "exp": 1710001800
}

Redis 里维护当前用户的有效会话：

auth:current_sid:{userId} = s_8f3a9c2e
auth:user_version:{userId} = 12
auth:session:{sid} = userId/device/ip/loginAt

每次请求的校验流程也很清楚：

1. 从 Authorization: Bearer <token> 中取出 JWT
2. 校验签名是否合法
3. 校验 exp 是否过期
4. 取出 sub、sid、ver
5. 查 Redis:
   - current_sid 是否等于 JWT.sid
   - user_version 是否等于 JWT.ver
   - session:{sid} 是否存在
6. 全部匹配，放行
7. 任意不匹配，返回 401

这样做以后，能力边界非常清晰：用户重新登录时覆盖 current_sid，旧 token 立即失效；用户修改密码时递增 user_version，所有旧 token 立即失效；管理员封号时删除 session 并标记用户状态，所有请求立即失败；单端登录只保留一个 current_sid；多端登录则把 current_sid 改成按设备维度管理的集合。

sid 和 version 的职责最好分开理解。sid 解决的是“这一次登录会话是不是当前有效会话”，适合单端登录、设备管理、主动踢某个设备。version 解决的是“这个用户整体安全状态有没有变化”，适合改密、封号、权限体系大变更。只靠 sid，你可以踢掉某次登录，但处理“所有历史 token 一起失效”会比较笨；只靠 version，你可以批量失效，但很难精细地区分某台设备。

刷新 token 的流程也应该和这个模型对齐。客户端拿短期 access_token 请求接口；快过期时，用 refresh_token 去认证服务换新的 access token；认证服务验证 refresh token hash、会话状态、用户版本和设备状态都正常以后，才签发新的 access token。更严格的系统会做 refresh token rotation：每次刷新都废掉旧 refresh token，签发一个新的，并记录 token 家族。如果发现一个已经轮换过的 refresh token 又被使用，说明可能发生泄露，应该吊销整个会话家族。

auth:refresh:{hash(refresh_token)} = {
  userId,
  sid,
  familyId,
  rotatedAt,
  expiresAt,
  revoked: false
}

这样写的好处，是你没有把长期凭证明文放在服务端；即便 Redis 或数据库中的记录泄露，攻击者也不能直接拿记录去冒充用户。它不能消灭所有风险，但把风险从“拿到即用”降成了“还需要原始 token”。

这套方案牺牲了纯 JWT 的“完全本地验签”，换来了服务端对会话生命周期的强控制。这就是交易。没有免费的架构。

真正成熟的选型，不是先站队，而是先看场景：

这里还要补一个很容易被忽略的点：refresh_token 不应该被服务端当明文长期保存。更稳的做法是保存它的 hash、家族关系、轮换版本和吊销状态。客户端侧也要看场景处理：浏览器里优先使用 HttpOnly、Secure、SameSite 合理配置的 Cookie，移动端放系统安全存储，不要把长期 refresh token 随手塞进普通本地存储。

access_token 则应该短。10 到 30 分钟是很多系统能接受的折中，具体要看风险等级和刷新成本。短 token 不能解决所有问题，但它能把泄露窗口压小，也能让黑名单不至于变成主路径。

如果你做的是后台管理、资金操作、企业内控系统，access token 可以更短，甚至在高风险操作前要求二次确认或重新认证。如果只是普通内容型 App，过短的 access token 会带来频繁刷新、移动网络抖动、用户体验下降的问题。这里没有一个放诸四海皆准的时间，只有风险和体验之间的账。

Redis 不该当垃圾桶：状态、黑名单与故障边界

很多人一上来就说“把 token 存 Redis”。这句话本身太粗糙了。

如果你把完整 JWT 原文直接存进去，然后每次拿客户端传来的 token 做字符串比对，也能工作，但不够优雅，也增加了敏感凭证泄露后的损害面。更好的方式是存 sid、jti 或 token hash：

auth:token_hash:{sha256(token)} = userId

或者只存当前有效的 sid：

auth:current_sid:10001 = s_8f3a9c2e

Redis 里也不应该塞无限增长的黑名单。黑名单适合处理短期异常，比如用户主动退出后，在 access token 剩余的几分钟内阻断它；如果 token 生命周期本身长达几天，再靠黑名单兜底，最后一定会变成运维债务。

黑名单最大的问题不是“不能用”，而是很容易被误用成主架构。它适合处理例外：某个 token 被怀疑泄露，用户主动登出后希望剩余几分钟内也不能用，或者安全系统临时拦截某个高风险凭证。它不适合承担所有会话生命周期控制。你越依赖黑名单，就越依赖每次请求都查黑名单；你 token 有效期越长，黑名单保留时间越长；用户越多，黑名单越像一个不断膨胀的安全垃圾场。

更稳的做法是：access_token 保持短期，refresh_token 支持轮换和吊销，会话控制通过 sid 和 version 完成，黑名单只处理极端安全事件，不做主路径设计。

同时，既然 Redis 成了会话控制面，就不能只讲能力，不讲故障。Redis 挂了怎么办？网络抖动怎么办？认证服务和 Redis 之间出现短暂分区怎么办？这些问题不提前定好，线上事故时就会变成临时拍脑袋。

对普通业务，我更倾向于认证链路 fail closed：Redis 查不到、查不动、查超时，就拒绝高风险请求，让用户重新认证。对低风险读接口，可以根据业务容忍度做短暂缓存或降级，但必须非常克制。因为登录态不是普通缓存，它是安全边界。你可以为了体验吞一点延迟，不能为了体验默认放行一个无法确认有效性的身份。

当然，fail closed 也不是一句口号就结束了。你要给 Redis 设置合理超时，不能让认证链路被一个慢查询拖死；要区分“Redis 明确返回会话不存在”和“Redis 暂时不可用”；要给登录、刷新、鉴权这些路径分别打指标，监控 Redis 延迟、命中率、错误率和 401/403 异常波动。很多认证事故不是因为方案错，而是因为系统不知道自己正在坏。

Redis key 也要有明确生命周期。auth:session:{sid} 应该带 TTL，auth:current_sid:{userId} 要和 session 生命周期保持一致，用户封号、改密、注销时要清理或递增版本。否则你以为自己获得了控制力，实际上只是把状态垃圾换了一个地方堆起来。

在多端登录场景里，key 结构还要再细一点。比如按设备保存 session，既能踢掉单台设备，也能在用户改密时一次性递增用户版本，让所有设备失效：

auth:user_version:{userId} = 12
auth:device_sessions:{userId} = set(deviceId...)
auth:session:{sid} = { userId, deviceId, ver, expiresAt }

这样，你可以清楚表达不同操作的影响范围：用户自己退出当前设备，只删当前 sid；管理员踢掉某台设备，只删对应 session；改密或封号，递增 user_version 并清理所有 session。状态不是越多越好，而是每一份状态都要有明确语义。

这部分的核心不是“Redis 很强”，而是“Redis 让状态变得可控”。可控的前提，是你承认它会失败，并且给失败留出边界。

WebSocket：长连接让状态无法回避

HTTP 请求是短连接语义。一次请求进来，验完就走。WebSocket 不一样，它是一条长时间挂在服务端进程里的连接。只要连接不断，用户就可能继续收消息、发消息、保持在线状态。

这意味着 WebSocket 天然有状态：哪个用户连在哪个节点，一个用户有几个连接，连接是否还活着，用户权限变了以后如何通知连接断开，某条消息应该推到哪些节点，节点重启后如何清理连接表。你不能拿“JWT 是无状态的”一句话解决这些问题。

握手阶段当然要鉴权，但 token 传递方式要谨慎。wss://example.com/ws?token=xxx 很常见，也很容易写进示例，但它不应该成为默认推荐，因为 query 参数容易进入日志、代理、监控和浏览器历史。浏览器场景可以考虑安全 Cookie、一次性握手 ticket，或者连接建立后的认证消息；非浏览器客户端可以使用握手 Header。确实要用 query，也应该使用短期、一次性、只用于换取连接身份的 ticket，而不是长期 access token。

如果 WebSocket 依赖 Cookie 鉴权，还要记得校验 Origin。浏览器发起跨站 WebSocket 时也可能自动带上 Cookie，服务端如果只看 Cookie 不看来源，就可能让恶意页面借用户身份建立连接。Cookie 方案不是不能用，但它必须和 Secure、SameSite、Origin 校验、TLS 一起讨论。

一个更稳的握手流程可以拆成两步：客户端先用正常 HTTP 请求向认证服务申请一次性 ws_ticket，服务端确认当前 access token、sid、version 都有效后，签发一个几十秒内有效、只能使用一次的 ticket；客户端再带这个 ticket 建立 WebSocket；WS 节点消费 ticket，换取用户身份并立刻作废。这样即便握手 URL 被日志记录，泄露窗口也很小。

1. HTTP: POST /ws-ticket，携带 access_token
2. Auth 校验 JWT + Redis sid/version
3. 返回一次性 ws_ticket，TTL 30-60 秒
4. WebSocket 握手携带 ws_ticket
5. WS 节点消费 ticket，建立 connId -> userId/sid/nodeId

握手通过后，本机内存保存真实 socket，Redis 只保存路由索引：

local:
  connId -> WebSocket 对象

redis:
  ws:conn:{connId} = { userId, sid, nodeId }
  ws:user:{userId} = set(connId...)
  ws:node:{nodeId} = set(connId...)

这里必须强调一句：真正的 WebSocket 连接不能存在 Redis。

Redis 只能告诉你“这个用户的连接在哪个节点”，不能替你跨进程操作 socket。真正能给客户端发消息的，永远是持有那条连接的进程。

单点登录、封号、修改密码后的踢下线，需要走事件通知：

1. 用户在新设备登录
2. Auth 服务生成 newSid
3. Redis 更新 auth:current_sid:{userId} = newSid
4. 发布事件 auth:kick:{userId}
5. WS 节点收到事件
6. 节点检查本机该 userId 的连接
7. 如果连接 sid != newSid，则主动 close

关闭时可以定义业务关闭码：

4001 token expired
4002 logged in elsewhere
4003 permission revoked
4004 account disabled

这样客户端可以根据关闭码做不同提示，而不是一句笼统的“连接断开”。

对于长连接，还要考虑 token 续期。第一种做法，是让 WebSocket 连接生命周期不超过 access token 生命周期，到期前客户端主动重连。它简单，适合小系统和对重连不敏感的业务。第二种做法，是连接内增加 refresh_auth 消息，客户端拿到新 access token 后发给服务端，服务端重新校验签名、sid、version 和用户状态，并更新连接上下文里的 expireAt。它更复杂，但适合 IM、协作编辑、交易行情这类不希望频繁断线重连的系统。

{
  "type": "refresh_auth",
  "accessToken": "new.jwt.token"
}

这一步不能只校验签名。用户可能已经被封号，密码可能已经修改，当前 sid 可能已经被新登录覆盖。如果连接内续期只看 JWT 是否没过期，就又绕回了“只认票据，不认会话事实”的老问题。

但这里还有一个工程细节：如果你用 Redis Pub/Sub 做踢下线通知，要承认它不持久化。节点重启或短暂掉线时，事件可能错过。因此小系统可以用 Pub/Sub，但最好配合心跳重验、定期校验 sid/version 或连接 TTL；如果踢下线必须可靠，就应该考虑 Redis Stream、RabbitMQ fanout/topic、NATS JetStream 或 Kafka 这类具备持久化或可回放能力的机制。

群聊和消息推送也是同一个原则：消息靠队列或事件总线路由，连接靠本机进程持有。节点 A 收到用户 A 的群消息后，可以写入 DB，投递 group_message 事件，事件里只放 messageId 和路由信息，消费者再去消息存储读取正文。这里不能笼统写“所有 WS 节点消费同一个队列”，因为普通队列通常是竞争消费，不会让每个节点都拿到事件。你要么使用 Pub/Sub、fanout exchange、topic 广播，要么提前算出目标 nodeId，把消息路由到持有连接的节点。

消息系统的选择也要围绕需求，而不是围绕名气。踢下线、权限刷新、在线状态广播，如果允许偶发事件通过心跳兜底，Redis Pub/Sub 可以先用；中小型 IM 需要可靠投递和消费确认，Redis Stream 或 RabbitMQ 更稳；大型群聊、消息审计、历史回放、跨服务追踪，Kafka 才更有意义；强实时推送和低延迟事件分发，可以评估 NATS。不要为了“架构漂亮”一上来就 Kafka，Kafka 解决的是大规模日志型事件和可回放，不是所有实时系统的默认答案。

连接索引也必须有清理机制。ws:conn:{connId}、ws:user:{userId}、ws:node:{nodeId} 这类 key 要有 TTL，连接心跳要刷新 TTL，正常断连要主动删除，节点宕机后要通过节点租约或定期扫描清理残留连接。否则 Redis 里的“在线用户”会慢慢变成一堆假在线。

更麻烦的是，连接状态往往和业务状态互相影响。用户已经离线但 Redis 里还残留连接，消息服务就可能继续向一个不存在的节点投递；用户已经被封号但某个 WS 节点错过踢下线事件，连接就可能继续存在；节点重启后本机连接全没了，但 Redis 还以为它持有一批 connId。分布式系统里，最危险的不是“没有状态”，而是“状态过期了却没人知道”。

所以分布式 WebSocket 的核心不是“所有节点都能发所有消息”，而是“所有节点都能知道消息该路由到哪里，然后由持有连接的节点完成投递”。这仍然是在讲会话控制：JWT 只能证明连接建立时“你是谁”，不能替服务端维护连接事实。

最后的判断：边界清晰比口号重要

如果要把上面的讨论落成一套可交付方案，我会这样设计：

客户端：
  - 保存短期 access_token
  - 安全保存或通过 Cookie 持有 refresh_token
  - HTTP 请求携带 Authorization
  - WebSocket 使用安全 Cookie、一次性 ticket 或连接内认证

认证服务：
  - 负责登录、刷新、注销、踢人
  - 生成 JWT
  - 维护 Redis 中的 sid/version
  - 保存 refresh token hash、轮换版本和吊销状态

Redis：
  - 保存当前有效 session
  - 保存用户版本号
  - 保存 WS 连接索引并设置 TTL
  - 发布踢下线和权限变更事件

WS 网关：
  - 握手时校验身份凭证 + Redis 状态
  - 本机内存保存 connId -> socket
  - Redis 保存 connId -> nodeId
  - 监听踢下线事件
  - 心跳重验 sid/version，清理失效连接

消息系统：
  - 按可靠性要求选择 Pub/Sub、Stream、MQ 或 Kafka
  - 广播或路由跨节点消息事件
  - 支持削峰、回放或跨节点分发

这套方案里的 JWT 仍然有价值：它让客户端凭证标准化，让网关和微服务可以快速解析身份，让跨服务调用不必每次都去数据库查用户。

但 Redis 也不可替代：它提供“当前是否还有效”的最终判断，提供踢人、封号、单端登录、WebSocket 连接路由这些强控制能力。

说白了，JWT 负责“你是谁”，Redis 负责“你现在还算不算数”。

很多技术争论最后都会变成口号对撞。有人说 JWT 高级，有人说 Session 稳妥；有人说无状态利于扩容，有人说有状态才方便管理。这些话单独看都对，但放到真实系统里都不完整。

纯无状态的代价是回收能力弱。只要 token 没过期，你很难优雅地让它立刻失效。纯有状态的代价是集中依赖强。只要 Redis 或 Session 服务出问题，认证链路就会被拖下水。

如果只是普通 API，短期 JWT 就足够。
如果要单端登录、踢人、封号、WebSocket 长连接、群聊分发，那就必须引入服务端状态。
如果用了 JWT + Redis，就大方承认它是混合架构，不要硬说自己纯无状态。

无状态不是银弹。它解决的是扩展性问题，不负责替你解决会话治理、主动吊销和长连接控制。

工程世界里没有神兵，只有边界清晰的取舍。能把需求、代价、故障模式和演进路径说清楚，比在群里争一个词更重要。