1. 令牌服务概述
咱们先聊聊什么是令牌服务。说白了，令牌就是一把“临时钥匙”。你拿着它，系统就知道你是谁、能干什么。我在早期做登录模块时，总是用 session 一把梭，后来发现跨服务、跨端根本调不通。嗯，从那时起我才认真研究令牌。
1.1 令牌服务的定义
令牌服务（ Service）负责生成、分发、校验和吊销令牌。令牌本身是一段结构化数据，通常包含用户身份、权限范围、有效期等关键信息。服务端只要验证令牌合法，就不再反复查数据库确认身份。
核心公式：令牌 = 身份 + 权限 + 时效 + 签名
我个人习惯把令牌服务比作“酒店前台”。你 check-in 时拿到房卡，前台只检查房卡是否在有效期内、能不能开这扇门。至于你是张三还是李四，房卡上写得很清楚，前台不会再打电话去总部核实。
1.2 令牌服务的作用
令牌服务不是花架子，它解决了几个关键痛点：
- 无状态认证：服务端不用存 session，水平扩展时零迁移成本
- 跨域/跨端共享：令牌可以放在 HTTP Header、Cookie 甚至二维码里，手机、网页、小程序都能用
- 细粒度权限控制：令牌里可以携带 roles、scopes，网关直接拦截，不用每次都落到业务层
- 防篡改：通过 JWT 签名或 OAuth 2.0 的 access 结构，客户端改了也没用
我曾经在项目中见过一个团队把整个用户表缓存到 Redis 里做鉴权，每次请求都要查一次。后来改令牌服务，响应时间从 12ms 降到 2ms。你想想看，这个差距在高并发下有多恐怖。
| 对比维度 | 传统 Session | 令牌服务 |
|---|---|---|
| 存储位置 | 服务端内存/Redis | 客户端持有 |
| 扩展性 | 需要 session 同步 | 天然支持水平扩展 |
| 跨域名 | 困难（Cookie 限制） | 轻松（Authorization header） |
| 吊销 | 直接删除 session | 需要黑名单或短有效期 |
避坑指南：我曾经直接把 JWT 有效期设成 7 天，结果一个离职员工拿旧令牌还能访问两天。后来我强制 refresh 机制 + 令牌黑名单，才把风险兜住。
1.3 常见场景
令牌服务不是银弹，但下面几个场景特别适合落地：
- 单点登录（SSO）：一个令牌打通企业所有内部系统。我在做内部 OA 时，直接用 OAuth 2.0 + JWT，三个系统共用一套鉴权。
- 移动端 API 鉴权：App 启动时申请 access ，后续请求携带令牌。避免重复登录。
- 微服务网关鉴权：网关统一校验令牌，提取用户信息并注入请求头，下游服务只管业务。
- 第三方开放平台：例如微信支付的回调通知，通过 验证调用方身份。
- IoT 设备认证：设备携带预置令牌（或通过 mTLS 获取临时令牌）连接云端。
为什么这些场景天然适合令牌？因为它们都涉及“信任边界变化”——要么跨服务、要么跨端、要么跨组织。令牌就像是一张一次性签证，网关或受信方检查签证齐整就直接放行。
1.4 知识体系框架
下面这张图概括了令牌服务的核心脉络，我们整个课程会围绕它展开：
一点建议：刚开始落地令牌服务时，不要一开始就搞自定义协议。先把 JWT 用熟，再根据业务折腾。我见过太多人上来就撸一个 格式，结果签名算法、过期逻辑、刷新机制全要重写，踩坑踩得怀疑人生。
1.5 从权限模型看令牌
我们的课程叫“权限模型在令牌服务中的落地实践”，所以需要提前交代：令牌只是载体，权限模型才是灵魂。常见的权限模型有 RBAC、ABAC、ReBAC 等，它们会映射到令牌的 claims 字段中。比如 RBAC 模型中，令牌里会携带角色列表；ABAC 模型中，令牌可能携带用户属性标签。
我记得有一次面试聊到一个创业团队，他们把用户的全部权限列表塞进 JWT，结果 体积飙到 4KB，超过千级个用户时每次请求头都大得吓人。优化方案是把权限模型抽离，令牌只存角色 ID，业务端通过缓存回查。这就是“令牌轻量化”原则，我们在后面章节会详细讲。
好了，这一章把令牌服务的基本概念、作用和场景讲清楚了。下一块内容会直接切入令牌的生命周期——从签发到吊销，每个环节都有设计取舍。咱们慢慢来。