服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

公司的一个用户改了密码，但改了之后发现手机上的 App 还是登录状态，能正常操作。查了半天发现是 JWT 的问题——旧 Token 还没过期，拿着旧密码签发的 Token 照样能通过验证。用户以为改密码后旧设备上的登录会失效，实际上 JWT 根本不关心密码是否被改过。 这就是 JWT 无状态设计带来的副作用。服务端不存任何 Token 状态，所以也没法"让它失效"。今天聊聊怎么在保持 JWT 无状态优势的前提下，解决"主动失效"的需求。 问题：为什么旧 Token 还能用 JWT 的验证逻辑只看三样东西： Token 的签名是否正确（证明它没被篡改） Token 是否过期（exp 字段） Token 的签发者是否正确（iss 字段） 它不看"这个用户的密码有没有被改过"。因为 JWT 的哲学是"服务端不记状态"——Token 自包含所有信息，验证时不需要查数据库。 这意味着一旦 Token 签发出去，在它自然过期之前，没有任何办法让它失效——除非你再往里加一个"失效机制"。 方案一：Redis 黑名单（最直观） 把需要失效的 Token 放进 Redis 黑名单里，验证时先查....

一、问题背景：JWT 的 CSRF 隐患 你是否认为使用 JWT 就天然安全？实际上，JWT 在某些场景下依然存在 CSRF 风险！ 当 JWT 存储在 Cookie 中（尤其是 HttpOnly=false 的情况），攻击者可以通过以下方式发起 CSRF 攻击： 用户登录你的网站，服务器返回 JWT 并存放在 Cookie 中 攻击者诱导用户访问恶意网站 恶意网站发起对目标网站的请求（如转账、修改密码） 浏览器自动携带 Cookie 中的 JWT，请求成功执行 真实案例：某电商平台的支付接口使用 JWT 认证，但未做 CSRF 防护。攻击者通过构造恶意页面，诱导用户点击后成功发起支付请求，造成用户资金损失。 二、核心概念：CSRF 与 JWT 的博弈 2.1 CSRF 攻击原理 ┌──────────────────────────────────────────────────────────────────┐ │ CSRF 攻击流程 │ ├──────────────────────────────────────────────────────────────────┤ ....

作为后端开发者，我们对 JWT（JSON Web Token）肯定不陌生。它解决了 Session 分布式一致性的问题，但是传统的 JWT 有个致命的缺陷：一旦签发，除非过期，否则无法强制失效。 你肯定遇到过这些场景： 用户修改密码后，旧的 JWT 还能用？ 用户丢失设备，想立刻踢掉旧设备登录的账号？ 管理员强制下线某个危险用户？ 用户主动退出登录，但 JWT 还在有效期内？ 如果用传统的 JWT 方案，这些问题都很难解决。今天我们就来聊聊如何通过 Redis 版本控制实现 JWT 的秒级强制失效。 为什么 JWT 难以强制失效？ 我们先回顾一下 JWT 的工作原理： 客户端登录 → 服务器签发 JWT → 客户端存储 JWT → 每次请求携带 JWT → 服务器验证 JWT → 通过则放行 JWT 的特点： 无状态：服务器不需要存储 JWT，只需要验证签名 自包含：JWT 本身包含了用户信息、过期时间等 签名验证：只要签名正确、未过期，就认为有效 问题就出在这里：JWT 是自验证的，服务器无法中途改变主意。 传统的解决方案通常是： 把 JWT 存在 Redis 里，每次请....

传统的Session认证方式虽然简单，但在分布式系统中却存在诸多问题：Session共享、服务器内存占用、扩展性差等。这时候，我们就需要更现代、更灵活的认证鉴权方案了。今天，我们就来聊聊两种主流的认证鉴权方案：JWT和Sa-Token，从资深后端工程师的角度分析它们的优缺点和最佳实践。