3. 常见授权模式对比： vs OAuth 2.0 vs 自签名JWT
聊到SDK的访问授权，其实绕不开三个老熟人：、OAuth 2.0和自签名JWT。
很多新手容易在这上面纠结，总觉得“越复杂越安全”。我个人觉得，选对模式比用对模式更重要。每个方案都有自己的“脾气”，用错了地方就会很别扭。
这一章我们就来掰扯清楚，它们各自适合什么样的场景，以及背后为什么这么设计。
3.1 三种模式的底层逻辑
先看一张图，把三种模式的本质摊开。
核心区别： 是“你是谁”，OAuth 2.0 是“你允许谁做什么”，自签名 JWT 是“我证明你是我信任的谁”。
为什么这么说？
- — 最简单的身份标识。就好像一把钥匙，只要钥匙对，门就开。它本身不区分权限粒度，一把钥匙走天下。
- OAuth 2.0 — 委托授权协议。你想象一下，你让一个代驾开你的车，代驾拿到的是“行驶权”，而不是你的车钥匙。它强调的是资源所有者和第三方应用之间的权限委托。
- 自签名 JWT — 自包含的令牌。由服务端签发，里面包含了用户身份、权限声明、过期时间等信息。客户端拿它可以“自证清白”，不需要每次都去数据库查权限。
我印象很深。之前有个项目，团队直接拿当用户凭证来用，结果用户A不小心泄露了Key，就能看到所有B用户的数据。嗯，这就是混用了“身份标识”和“授权凭证”的典型问题。
个人建议：我习惯在项目初期先画这样的决策树，把“用户交互边界”和“信任域”画清楚。边界不清晰的时候，授权策略很容易做出“四不像”。
3.2 逐项拆解：优缺点与适用场景
光看定义还不够，我们来逐个盘一盘它们的实战优缺点。
3.2.1 ：简单但粗糙
的优点很直白：实现简单、部署成本低。你生成一个Key，服务端查一下库，就完事了。
- 优点：易于集成，适合内部工具、开发调试、低安全敏感度的场景。
- 缺点：权限粒度粗，难以做精细的scope控制；泄露后只能吊销再重新生成，无法做到“临时授权”。
这里有一个我曾经踩过的坑：把硬编码在客户端代码里。那时候刚接手一个老项目，前端直接暴露了一个全局变量存Key，f12 一眼就能看到。嗯，结果被外部爬虫盯上了，流量直接被打爆。后来紧急切成了服务端代理+OAuth。
警告：千万不要在前端代码中硬编码！这几乎等同于把门钥匙挂在门外面。你可以参考下你的浏览器开发者工具里的“网络”面板，看看有没有类似情况。
适合场景：
- 内部微服务之间的快速验证（比如开发环境、测试环境）
- 只读型的数据访问（比如公开的天气API、汇率API）
- 短期临时的功能测试
3.2.2 OAuth 2.0：专业但复杂
OAuth 2.0 解决的是“第三方应用申请访问用户资源”的问题。它通过授权码、令牌刷新、scope等机制，把权限控制得很细。说白了，它是授权领域的工业标准。
- 优点：安全机制成熟（支持refresh 、revoke等），scope精细控制，适用于跨系统授权、开放平台。
- 缺点：实现成本高，需要认证授权服务器；流程复杂（尤其是Authorization Code + PKCE），对小型项目来说有点“杀鸡用牛刀”。
我过去在做一个开放平台SDK时用过OAuth 2.0。那时候觉得它很重，但后来发现用户想授权第三方查看自己的历史数据时，你就需要分离“登录”和“授权”。OAuth 2.0 里那个授权码流程，就是专门干这个的。你想想看，如果没有这个机制，你的SDK就得把用户密码交给第三方，这安全风险太大了。
关键点：OAuth 2.0 是不关心“你是谁”的，它只关心“你允许第三方做什么”。身份认证（Authentication）是OpenID Connect（OIDC）的工作，不要混了。
3.2.3 自签名JWT：灵活但需要信任基础
自签名JWT，就是不依赖外部认证服务器，由服务端自己签发、自己验证。它内部带有签名和声明（claims），数据是自包含的。我最喜欢用它来做内部微服务之间的无状态认证。
- 优点：无状态，不需要查数据库或缓存，性能好；可以携带自定义数据（比如用户角色、租户ID），减少后续查询。
- 缺点：无法即时吊销（除非用黑名单方案）；密钥管理风险高，一旦泄露，所有签发的JWT都失去安全性。
适合场景：
- 服务网格内部的服务间通信（例如Istio、gRPC认证）
- 短期的、一次性的API调用（比如上传附件的凭证）
- 内部管理系统，系统内各模块之间的调用
避坑指南：我曾经遇到过团队把自签名JWT的过期时间设成一年。理由是“用户懒得重新登录”。结果密钥泄露后，整个系统瘫痪了一周。现在我建议：自签名JWT的过期时间不要超过15分钟，必须配合refresh 机制来续期。
3.3 对比表格：一眼看清差异
为了让你更直观地对比，我整理了一个表格：
| 维度 | OAuth 2.0 | 自签名JWT | |
|---|---|---|---|
| 权限粒度 | 粗（通常整个应用级别） | 细（scope、resource级别） | 中（通过claims自定义） |
| 是否可吊销 | 简单（删Key即可） | 容易（revoke ） | 困难（需维护黑名单） |
| 实现复杂度 | 低 | 高 | 中 |
| 是否依赖第三方服务 | 否 | 是（需要认证服务器） | 否（自签发/自验证） |
| 是否无状态 | 否（需查库验证Key） | 是（本身包含授权信息） | 是（JWT本身包含签名和claims） |
| 适用场景 | 内部工具、公开API、开发调试 | 开放平台、第三方登录、跨系统授权 | 微服务间通信、短效凭证、内部调用 |
通过这个表格，你大概能感受到：复杂度和安全性往往是正相关的。不要为了“省事”而过度简配，也不要为了“炫技”而过度复杂化。
3.4 实战决策：我该选哪个？
在实际项目中，我一般会按下面的思路来快速判断：
- 首先，有没有用户委托第三方访问资源的场景？ 如果有，直接选OAuth 2.0。不用多想。
- 其次，调用方和服务方是否在同一个信任域内？ 比如都是内部服务。如果是，看是否需要无状态和性能优势：需要就去自签名JWT，不需要就用也挺好。
- 最后，如果两者都不是，比如你要对外提供一个第三方SDK，但第三方只是来拿数据（没有用户委托），那其实就够用。但记得加上IP白名单、速率限制等额外安全防护。
经验谈：我记得有一次做金融类SDK，对方要求必须支持“用户授权给第三方查看交易记录”。当时团队里有声音说“用吧，简单”。但我知道，无法支撑“授权范围细化”的需求——你总不能把用户的所有数据都暴露给第三方吧？最后还是老老实实上了OAuth 2.0。上线后，安全审计一次过，没出过问题。
3.5 总结性思考
授权模式这件事，本质上是对信任边界的切分和管控。
- 信任一个“应用身份”。
- OAuth 2.0 信任一个“委托关系”。
- 自签名JWT 信任一个“自包含声明”。
没有银弹。你需要在实现成本、安全等级、用户体验之间找平衡点。我个人更喜欢在面对新项目时，先默认采用“ + 黑白名单”的简单方案进行原型验证，待业务逻辑和边界清晰后，再根据实际威胁模型升级为OAuth或JWT。
嗯，合理就行。毕竟SDK的核心是“服务于开发者”，而不是“折磨开发者”。