2. 的类型与结构：JWT、OAuth2 、
做密钥迁移，你首先得搞清楚手里拿的是什么。 看起来都是一串乱码，但内里结构天差地别。我见过不少团队，迁移到一半才发现 类型搞错了，结果整个流程要重来。咱们先花点时间，把这几种常见的 理清楚。
核心结论：迁移策略取决于 的“自包含程度”和“生命周期”。有的 可以直接换，有的必须依赖认证中心。
2.1 JWT（JSON Web ）
JWT 可能是目前用得最广的一种 。说白了，它就是一个“自包含”的令牌——你拿着 JWT，不需要找服务器就能验证身份。因为所有信息都编码在令牌本身。
它的结构长这样：
# JWT 由三部分组成，用点号分隔
xxxxxxxxx.yyyyyyyyy.zzzzzzzzz
# 分别是 Header.Payload.Signature我拆开给你看：
| 部分 | 内容 | 示例 |
|---|---|---|
| Header（头部） | 签名算法 + 类型 | {"alg":"HS256","typ":"JWT"} |
| Payload（载荷） | 用户信息 + 过期时间等声明 | {"sub":"user123","exp":1700000000} |
| Signature（签名） | 防篡改的校验码 | HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload), secret) |
⚠️ 常见坑：Payload 只是 Base64 编码，不是加密！我见过有人把密码直接放 JWT 的 Payload 里，以为没人能看到。任何拿到令牌的人都可以解码读取。
迁移 JWT 时，你要注意一个核心矛盾：JWT 一旦签发就没办法主动作废。我踩过这个坑，当时我们换签名密钥，老的 JWT 还在用，被迫搞了一个黑名单缓存——这完全违背了 JWT 的设计初衷。
我的建议：JWT 的过期时间别设太长。生产环境我个人习惯设 15 分钟到 1 小时。配合 refresh 来实现长效登录。
2.2 OAuth2
OAuth2 其实是个授权框架，不是一种具体的 。但实际使用中，我们常说的 OAuth2 特指 Access 和 Refresh 这对组合。
它的运行逻辑是这样的：
- 客户端去授权服务器要令牌
- 授权服务器返回 Access （短期有效）和 Refresh （长期有效）
- 客户端用 Access 访问资源
- Access 过期，用 Refresh 换新的
迁移 OAuth2 解决方案时，你通常不需要改 Access 本身的格式，但要协调好授权服务器的配置变更。举个例子，我们做过一个迁移，要把授权服务器从自建 Auth0 换成 AWS Cognito，关键工作是把转发规则和 scope 映射做对。
| 令牌类型 | 生命周期 | 存储位置 | 迁移影响 |
|---|---|---|---|
| Access | 短（通常 15-60 分钟） | 客户端内存 / 缓存 | 随迁移自然失效，影响小 |
| Refresh | 长（天、周甚至月） | 客户端持久存储 | 需主动刷新或重新认证 |
要点：OAuth2 迁移的难点不在 本身，而在“安全链”的切换。客户端、授权服务器、资源服务器三者必须步调一致。我习惯在切换窗口期内让新旧认证源同时接受请求。
2.3
是最简单的身份标识。它通常是一个固定字符串，由服务端生成，客户端拿着它来证明身份。常见于服务端之间的通信。
它的特点很明显：
- 简单直接——没有签名，没有有效期概念（通常人为设定）
- 不携带用户信息——就是一个标识符，不做身份断言
- 安全性低——泄露了就是灾难，因为没法按用户粒度撤销
我曾经见过一个项目， 写死在代码里，一用就是三年。迁移的时候才发现，根本不知道还有哪些服务在用这个 Key。最后只能一个个查日志。
⚠️ 避坑指南： 迁移时一定要做“双 Key 共存”。生成新 Key，让客户端慢慢切换到新 Key，等旧 Key 流量归零再停用。我吃过一次性替换的亏——有些客户端没通知到，直接断掉线上服务。
2.4 对比与选择指南
三种 各有适用场景。我整理了一张对比表：
| 维度 | JWT | OAuth2 | |
|---|---|---|---|
| 是否自包含 | 是 | 否（需要校验） | 否（只是一个 ID） |
| 携带用户信息 | 可以 | 间接通过 scope | 不能 |
| 生命周期 | 固定过期 | 可刷新 | 由人决定 |
| 能否撤销 | 难 | 可以（在授权服务器侧） | 可以（停用该 Key） |
| 主要风险 | 签名密钥泄露、载荷泄密 | 授权服务器 DDoS、令牌劫持 | 静态泄露、权限过大 |
| 典型场景 | 单点登录、API 网关鉴权 | 第三方登录、微服务授权 | 内部服务通信、SDK 认证 |
选型原则：我个人的经验是——需要离线验证选 JWT，需要第三方授权选 OAuth2，服务间简单通信可以用 。但记住， 不是银弹，长期项目我建议逐步往 JWT 或 OAuth2 迁移。
为什么？因为 没法绑定具体用户，也没法跟踪操作者。你想想看，出了问题只能知道“某个 Key 调用了”，但谁用的、什么目的完全不知道。
再说个现实问题。我们做 迁移时，往往不是只换一种 ，而是要同时处理多种并存的情况。比如旧系统用 ，新系统用 JWT，中间有过渡桥接。这时候搞清楚每种 的结构和生命周期，才能设计出不会断流的迁移方案。