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？
“你能不能访问 my-project？”	GitHub 的权限系统（你是仓库所有者）	❌ 不属于
“第三方 App 能不能通过你的授权访问 my-project？”	你点击‘同意’授权 + GitHub 的 OAuth 服务	✅ 属于 OAuth 2.0

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

---

三、权限体系的分层模型

• 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 权限管理系统

 

功能	OAuth 2.0	权限管理系统（如 RBAC）
定义用户角色	❌ 不支持	✅ 支持（如 admin, user）
分配权限给角色	❌ 不支持	✅ 支持
判断用户能否访问资源	❌ 不直接判断	✅ 核心功能
委托临时访问权给第三方	✅ 核心功能	❌ 不涉及
管理 Token 生命周期	✅ 是	❌ 否

---

七、对架构设计的启示

✅ 正确做法：

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

❌ 错误做法：

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

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

---

八、总结

 

问题	答案
资源所有者的权限从哪里来？	来自系统本身的权限模型（如你是文件所有者、你有 admin 角色等）
OAuth 2.0 管理这个权限吗？	❌ 完全不管。它假设权限已存在，只处理“委托”
那 OAuth 2.0 作用是什么？	安全地将已存在的权限，临时授予第三方客户端
谁负责权限管理？	授权服务器背后的 IAM 系统（如用户中心、RBAC 引擎）

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

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