我真的厌倦了假装 #JWT（JSON Web Token）很好用。事实上面对现实吧：它是一个盲目崇拜的产物（Cargo Cult）。它解决了一个你的应用几乎绝对不存在的问题，却带来了四五个你的应用绝对会遇到的麻烦。整整一代后端开发者被 2014 年左右的某些博客文章所误导，把“无状态（Stateless）”当成了一种绝对的美德，而不是一种权衡（Trade-off）。
在实际的项目审计中，我发现每一个基于 JWT 的系统都存在相同的问题：破碎的凭证撤销机制、毫无意义的双 Token 刷新逻辑，以及前端直接解码并信任 Payload 数据的安全漏洞。如果你正在构建 Web 应用、移动 App 或第一方 API，JWT 绝对是错误的默认选择，请立即停止使用它。在 Postgres 中存一行 Bearer Token 记录，不仅更快、更简单，而且严格来说更加安全。
让我们剖析一下 JWT 的本质。JWT 由三部分组成：头部（Header）、JSON 载荷（Payload）和签名（Signature）。签名通常是 HMAC 或 RSA/ECDSA 算法生成的。它的卖点在于：服务器签名，客户端携带，随后的每次请求只需进行签名验证，无需查询数据库，从而实现“无状态身份验证”。这就是它的整个价值主张。然而，只要问一个问题，这个美妙的谎言就会不攻自破。
那就是：在过期时间（exp）截止前，你如何让一个用户强制下线？
答案是：你做不到。在 Token 到期之前，它永远有效。唯一的撤销方法是在服务端维护一个黑名单（Revocation List），并在每次请求时查询该列表。这不仅需要数据库查询，而且直接击碎了 JWT “免去数据库轮询”的初衷。恭喜你，你以极其拙劣的方式重新发明了 Session（会话管理）。
最终，你只能在两个糟糕的方案中做二选一：
第一，不进行即时撤销。被盗取的 Token 在过期前持续有效。为了不让用户频繁登录，生产环境中充斥着有效期长达 1 年、5 年甚至 10 年的 Token。这意味着“退出所有设备”按钮名存实亡，重置密码也无法踢出攻击者。
第二，维护撤销列表。此时你既要承担 JWT 签名验证的 CPU 开销，又要承担数据库/Redis 的查询开销，得不偿失。在这两者之间，从来没有第三种选择。
随着 AI Agent 走向主动执行与多 Agent 协同，身份验证（Auth）的底座正在发生根本性改变。在 Agent 生态中，Agent 拥有极高的 API 调用自主权，极易遭受提示词注入或行为失控。在这种场景下，JWT 的“无状态、难即时撤销”特性的隐患被无限放大。如果一个 Agent 出现异常，安全系统必须具备“微秒级”的即时阻断能力。传统的无状态 JWT 无法做到这一点，而基于 #MCP（Model Context Protocol）或有状态 Bearer Token 的动态权限校验，能够实现对 Agent 权限的实时收紧与吊销。未来，面向 Agent 时代的 Auth 方案必将抛弃 JWT 这种粗放的无状态签名，转向具备极细粒度、实时可控的“有状态能力令牌（Capability-based Tokens）”，这才是支撑高频、动态 Agent 协作的安全基石。
