2. 令牌类型与格式：JWT、Opaque 、Reference 的区别与选型

聊令牌服务，绕不开令牌本身。你想想看，用户登录后拿到的那串字符串，到底是个什么东西？我见过不少团队，一开始都随便选一种，直到线上出了性能问题或者安全漏洞，才回头来补课。

令牌（）说白了，就是客户端向服务端证明身份的凭证。但凭证也有不同玩法。今天我们就来拆解三种最主流的令牌类型：JWT、Opaque 和 Reference 。我会结合我在项目中踩过的坑，帮你理清楚什么时候该用哪个。

2.1 三种令牌的核心差异

先看一张总览表，对它们有个整体印象。

特性 JWT Opaque Reference
自包含性 是（携带用户信息和元数据） 否（仅凭令牌字符串无法解析） 否（本质是一个指针）
存储位置 客户端 服务端 服务端（如Redis、数据库）
验证方式 本地解析 + 签名校验 远程调用验证服务 远程查找映射关系
可撤销性 难（需黑名单或短TTL） 容易（删除服务端记录） 容易（删除映射记录）
性能开销 低（无网络I/O） 中（每次需远程调用） 中（类似Opaque，但依赖后端存储）
典型场景 分布式系统、无状态API 高安全要求、内部服务 Session替代、需要兜底查详情

2.2 JWT——无处不在的自包含令牌

JWT，全称是JSON Web 。它长什么样？一段用点号分隔的字符串，例如：

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.1sVfDxl3kff3jC9k7vk3gJ0t5q0C1w2x3y4z5a6b7c8d9e0f

它分为三部分：Header（头部）、Payload（载荷）、Signature（签名）。

优点很明显：无状态。 服务端接收JWT后，可以用密钥或公钥本地验证签名，不需要查数据库。这在微服务架构里简直是神器。我在一个电商项目里，把用户登录后的JWT传给多个下游服务，每个服务都能独立解析出用户ID和角色，免去了集中认证的压力，爽得很。

但

陷阱也有不少

：

  • 令牌太长。 JWT 的 Payload 如果塞入过多自定义声明，Header 会很臃肿。我记得有一次，团队把用户完整的权限列表写进JWT，结果每个请求的HTTP头多了2KB，移动端客户直接投诉网络开销太大。
  • 难以撤销。 服务端没法主动让一个JWT失效，除非维护一个黑名单。但如果黑名单太大，又失去了无状态的优势。
  • 过期时间难掌控。 TTL设短了用户频繁重登录；TTL设长了，泄露风险大。
避坑指南： 我曾经在金融项目里滥用JWT，把用户敏感个人信息（如手机号、地址）直接塞进Payload。遭遇安全审计后，被要求必须移除。记住，JWT的Payload只是Base64编码，不是加密，大家都能解码。敏感数据一定不能放。

2.3 Opaque ——不透明的安全令牌

Opaque ，字面意思就是不透明的令牌。它就是一串随机生成的字符串，可能像这样：

a8b7c6d5e4f3g2h1i0j9k8l7m6n5o4p3q2r1s0t

你拿着它，完全看不出它代表什么。服务端收到后，必须拿着这个字符串去验证服务（如 OAuth2 的 Introspection Endpoint）查询，才知道这个令牌是否有效、属于哪个用户。说白了，它是一个“指针”。

我为什么推荐某些场景用Opaque ？

  • 安全可控。 令牌内容不暴露给客户端，无法伪造。服务端想让它失效，只要在存储里删掉记录即可。
  • 长度固定。 一个 UUID 或随机字符串，长度总是那么几十个字节。网络传输开销极低。
  • 灵活性高。 你想在令牌关联什么数据都行，到时候查存储时动态获取。

但它也有硬伤：每次验证都要发出网络请求。如果验证服务挂了或网络延迟，整个API就跟着慢。我记得有个朋友，他们公司把所有API的鉴权都走Opaque + Redis，流量高峰期Redis稍微抖动一下，接口响应时间从10ms飙到200ms，业务几乎不可用。

经验之谈： 我个人习惯在内部服务间使用Opaque 。因为内部网络延迟低，稳定性高，而且我能完全控制验证服务的负载。但在面向公网的API网关层，我通常不直接用Opaque ——太依赖后端存储了。

2.4 Reference ——兼有之长的折衷方案

Reference ，它和Opaque 很像，也是一串随机字符串，但它多了一个关键特性：服务端可以存储与令牌关联的丰富元数据。

Opaque 严格来说就是一种Reference 的简化版。但Reference 更强调“引用”的含义。常见实现是：令牌是key，值是用户信息、权限列表、会话上下文等。典型存储是Redis，value可能是JSON字符串。

那它和JWT的区别呢？JWT把数据塞进令牌本身，而Reference 把数据留在服务端。你可以这样理解：

  • JWT：令牌就是数据，你拿到它就能干活。
  • Reference ：令牌是钥匙，你拿着它去开锁拿数据。

优势很明显：随时可以修改关联数据。比如用户权限变了，我只要在存储里更新一下，令牌本身不需要换。这在JWT里是做不到的（除非重新签发）。

劣势呢？跟Opaque 一样，依赖后端存储。而且如果存储挂了，所有令牌都失效，这就是典型的单点故障。

2.5 如何选型？——我的决策树

你肯定想知道实际项目里怎么选。嗯，我给你一个基于经验的决策思路，可以对照着用：

  1. 先问自己：我需要服务端主动撤销令牌吗？
    • 需要 → 排除JWT，考虑Opaque/Reference 。
    • 不需要 → JWT是首选，轻量高效。
  2. 再问：验证的响应时间敏感吗？
    • 非常敏感（如毫秒级API） → 选JWT，本地验证无I/O。
    • 可接受几毫秒到几十毫秒的延迟 → 考虑Opaque/Reference。
  3. 然后问：令牌需要携带大量用户数据吗？
    • 需要（如用户基础信息+权限+角色） → 选JWT或Reference 。但JWT要注意令牌大小。
    • 不需要（只凭令牌ID即可） → Opaque 足够。
  4. 最后：你的架构是无状态还是有状态？
    • 无状态（如K8s集群、无共享存储） → JWT。
    • 有状态（有Redis、数据库） → Opaque/Reference 可以更灵活。
核心结论：
  • JWT：适合无状态、分布式、性能敏感、接受短TTL的场景。
  • Opaque ：适合高安全、内部服务、需要随时撤销令牌的场景。
  • Reference ：适合Opaque 的增强版，需要存储额外上下文且要求快查快的场景。

2.6 让我用一张SVG图帮你理清选型逻辑

令牌类型选型决策树 开始选型 需要服务端主动撤销令牌？ 是 否 验证延迟敏感？ 否 是 Reference （有存储+快查） Opaque （最小化存储） 令牌需携带大量数据？ 是 否 JWT （注意令牌大小） JWT（无状态） （最轻量方案） 决策说明 • 需要撤销 + 延迟不敏感 → Opaque • 需要撤销 + 延迟敏感 → Reference • 不需要撤销 + 需要携带数据 → JWT • 不需要撤销 + 无数据需要 → JWT（无状态）

2.7 说点实用的总结

嗯，三种令牌各有优劣，没有银弹。我的建议是：先搞清楚你的核心约束是什么。

  • 如果你追求极致的性能和分布式友好，JWT 是很香的，但要接受它不可撤销的代价。
  • 如果你对安全要求极高，或者需要随时踢人下线，Opaque/Reference 更适合。
  • 如果你需要在令牌上附加灵活查改的数据，Reference 能让你睡得安稳。

别被花里胡哨的概念迷惑。说白了，令牌就是一个凭证，你选的是凭证的“工作方式”。在实际项目中，我常常会混用：面向客户端的API用JWT（方便），内部服务间用Opaque （安全）。这并不矛盾，关键是要想清楚它们分别解决什么问题。

← 上一章 📖 返回目录 下一章 →