OAuth 2.0 的根本边界

一、OAuth 2.0 是一个“授权委托协议”

• OAuth 2.0 是一个“授权委托协议”（Delegated Authorization Protocol）， 它只解决一个问题： OAuth 2.0 不管理、也不关心“资源所有者的权限从哪里来”。它只是关心如何让客户端在用户同意后，临时获得访问其资源的权限。
• 它不解决以下问题：
  • 用户本身有没有权限访问某个资源？（这是资源服务器或 IAM 系统的事）
  • 用户的权限是谁分配的？（这是用户管理系统 / RBAC / ABAC 的事）
  • 用户身份是否合法？（这是认证系统 / IdP 的事）

🔑 OAuth 2.0 假设：资源所有者天然拥有对自己资源的完全控制权。

二、权限的真正来源：不在 OAuth 2.0 中

🌰 举个例子：

假设你在 GitHub 上有一个私有仓库 my-project。

→ OAuth 2.0 只处理第二层：一旦你是仓库所有者（第一层已成立），它帮你安全地把“访问权”临时委托给第三方。

三、权限体系的分层模型

tongyi-mermaid-2026-01-14-220544

• OAuth 2.0 只覆盖第 4 层。
• 第 1～3 层由企业 IAM（身份与访问管理）系统负责，例如：
  • Keycloak、Auth0、Okta（提供用户+角色管理）
  • Spring Security + 数据库（自建 RBAC）
  • AWS IAM、Azure AD

四、OAuth 2.0 的“信任前提”

RFC 6749 隐含了一个关键假设：

“资源所有者对其请求访问的资源拥有完全的控制权。”

这意味着：

• 如果用户 A 没有权限读取某条数据，他根本不会看到“授权第三方访问”的选项；
• 授权服务器在展示授权页面前，应确保该用户确实拥有这些 scope 对应的资源权限；
• 但这个“检查权限”的动作，不是 OAuth 2.0 协议定义的，而是授权服务器自身的业务逻辑。

💡 举例： 微信不会让你授权一个 App 访问“你朋友的聊天记录”，因为你根本没有这个权限。 所以授权页面只显示你能授权的 scope（如你的头像、昵称）。

五、那权限信息怎么传递给资源服务器？

虽然 OAuth 2.0 不管理权限来源，但它可以通过 Access Token 携带权限信息，供资源服务器使用。

方式 1：Scope（最常见）

• 客户端申请 scope=read_profile
• 授权服务器验证用户是否有 read_profile 权限
• Token 中包含 scope: "read_profile"
• 资源服务器根据 scope 决定返回哪些字段

方式 2：JWT Claim（结构化权限）

{
  "sub": "user123",
  "scope": ["read", "write"],
  "roles": ["user", "premium"],
  "permissions": ["order:read", "payment:create"]
}

→ 资源服务器解析 JWT，直接获取细粒度权限。

⚠️ 但注意：谁往 Token 里写这些权限？ 是授权服务器根据其内部权限系统（如数据库查用户角色）决定的——这仍是授权服务器的实现细节，非 OAuth 2.0 规范内容。

六、对比：OAuth 2.0 vs 权限管理系统

七、对架构设计的启示

✅ 正确做法：

1. 先有健全的权限体系（谁有什么权限）
2. 再用 OAuth 2.0 实现“委托”（让用户把已有权限临时给第三方）

❌ 错误做法：

• 试图用 OAuth 2.0 的 scope 替代 RBAC（scope 不是权限模型！）
• 让客户端直接决定能申请什么 scope（应由授权服务器根据用户实际权限过滤）

🛡️ 最佳实践： 授权服务器在生成 Token 前，应调用内部权限服务，只将用户实际拥有的权限放入 Token。

八、总结

🧠 终极理解： OAuth 2.0 不是“权限系统”，而是“权限快递员”。 它不生产权限，只是把权限从用户手里安全地送到第三方手上。

OAuth 2.0 的力量恰恰在于它的“专注”：只做委托，不做权限管理。这也正是它能与各种权限模型无缝集成的原因。