文章反复提到 BFF 是 SPA 认证的『规范答案』，但很多人只知其名不知其用。BFF 的核心不是某个技术栈，而是一层『有状态的代理』——它把 access token 和 refresh token 全锁在服务端，浏览器只拿一条 HttpOnly 会话 Cookie，前端脚本根本摸不到令牌。这样 XSS 攻击面大幅收窄，同时还能帮前端做数据聚合、协议转换。IETF 在 2025 年定稿的 RFC 10017 把这条路正式标准化，阿里、腾讯的微服务实践也都把 BFF 作为认证边界。

反方阵营的核心论据并不是否定『不可撤销』，而是分场景讨论。在服务间调用场景下，JWT 的自包含特性让每个服务无需查中心缓存就能做本地验签，性能优势明显。另一条线来自微服务网关生态：Istio、阿里云 API 网关、华为 ASM 都把 JWT 作为服务网格内的认证标准，因为网关可以统一处理验签和 JWT 转换，将认证逻辑从业务服务中剥离。Red Hat 的 Keycloak 也用 JWT 做跨域令牌交换。两边吵的不是技术对错，而是『谁来背中心存储这还是每个节点自己验』的架构选型。

JWT 与 Session 之争的根源是『无状态 vs 可控』的两难，而 Passkey（通行密钥）直接绕过这个矛盾——它用设备本地非对称密钥替代所有网络传输的凭证，私钥永远不出设备，公钥注册在服务端。微软、苹果、谷歌已全线入局，FIDO2/WebAuthn 标准完善，腾讯云国际站 2024 年已支持。但 Passkey 当前的主要障碍是跨设备同步和账户恢复：苹果锁 iCloud 钥匙串，谷歌锁密码管理器，生态互通尚未统一。2025 年底 FIDO 联盟计划发布跨平台密钥托管标准，一旦落地，JWT 与 Session 可能同时退居到『存量兼容』的位置。

文章说『一旦引入黑名单，无状态的前提就不复存在』，这话没错，但极端场景下真正要问的是：千万级用户同时登出，全量 token 写入 Redis 黑名单会直接撑爆内存（一个 token 约 300 字节，1000 万条就是 3GB 级存储）。业内给出的解法是用『Token 版本号+白名单』替代全量黑名单——不给每个失效 token 建 key，而是给每个用户存一个当前版本号，JWT payload 里带上版本，校验时只查版本是否匹配。这样存储量从 O(N) 降为 O(用户数)，且版本号本质上还是集中存储，只不过换了一种更经济的形态。