OAuth2.0协议(RFC 6749)中定义的四大核心角色

资源所有者（Resource Owner）、资源服务器（Resource Server）、客户端（Client） 和 授权服务器（Authorization Server）——是 OAuth 2.0 协议（RFC 6749） 中定义的四大核心角色。它们共同构成了 OAuth 2.0 委托授权模型的基础。

下面逐一详解每个角色的定义、职责、典型示例及相互关系，帮助我建立清晰的系统认知。

一、资源所有者（Resource Owner）

✅ 定义

能够授予对受保护资源访问权限的实体。

• 在绝大多数场景下，资源所有者就是“用户”（End User）。
• 例如：我在使用“第三方 App 登录 GitHub”时，我本人就是资源所有者。

🔑 职责

• 决定是否授权某个客户端访问自己的数据。
• 在交互式流程中（如授权码模式），需要登录并点击“同意”。
• 拥有对自身数据的最终控制权。

🌰 典型示例

⚠️ 注意：虽然 RFC 6749 允许资源所有者是“机器”，但实践中几乎总是人类用户。

二、资源服务器（Resource Server）

✅ 定义

托管受保护资源的服务器，能够接收并响应携带 Access Token 的请求。

• 它不负责认证用户，只负责验证令牌（Token）是否有效，并据此决定是否返回资源。
• 通常就是我的 RESTful API 服务。

🔑 职责

1. 接收来自客户端的请求（如 GET /api/user/profile）
2. 从请求头中提取 Authorization: Bearer <access_token>
3. 验证该 Token：
   • 是否未过期？
   • 是否由可信授权服务器签发？
   • 是否包含所需权限（scope）？
4. 若验证通过，返回受保护资源；否则返回 401 Unauthorized 或 403 Forbidden

🌰 典型示例

💡 资源服务器必须信任授权服务器，或能独立验证 Token（如通过公钥验签 JWT）。

三、客户端（Client）

✅ 定义

代表资源所有者发起请求、获取 Access Token 并访问资源服务器的应用程序。

• 它是整个流程的发起者，但不能直接访问用户凭证（如密码）。
• 可以是 Web 应用、移动 App、后端服务等。

🔑 职责

1. 向授权服务器申请授权（引导用户登录/同意）
2. 获取 Access Token
3. 携带 Token 调用资源服务器 API
4. （可选）使用 Refresh Token 刷新过期的 Access Token

🌰 典型示例

⚠️ 客户端必须提前在授权服务器注册（提供 client_id、client_secret、redirect_uri 等）。

四、授权服务器（Authorization Server）

✅ 定义

负责验证资源所有者身份，并向客户端颁发 Access Token 的服务器。

• 它是 OAuth 2.0 的核心枢纽，实现协议标准流程。
• 必须安全地管理客户端注册、用户认证、令牌生命周期。

🔑 职责

1. 认证资源所有者（如展示登录页）
2. 验证客户端身份（通过 client_id + client_secret）
3. 处理授权请求（如用户点击“同意”）
4. 签发 Access Token（和 Refresh Token）
5. （可选）提供 Token 校验或公钥分发接口

🌰 典型示例

🔐 授权服务器绝不应将用户密码透露给客户端——这是 OAuth 2.0 的根本安全原则。

五、四大角色协作流程（以“授权码模式”为例）

tongyi-mermaid-2026-01-14-214011

✅ 关键点：

• 用户只在授权服务器输入密码
• 客户端从未接触用户密码
• 资源服务器只认 Token，不关心用户如何登录

六、常见误区澄清

七、总结

💡 最后建议

• 设计系统时，先画出这四个角色，明确数据流和信任边界。
• 永远不要让客户端直接接触用户密码——这是 OAuth 2.0 的灵魂。
• 新项目优先使用 Authorization Code + PKCE 模式，避免已弃用的 Implicit 或 Password 模式。
• 若需用户身份信息（如登录名、邮箱），请使用 OpenID Connect（OIDC），它是构建在 OAuth 2.0 之上的身份层。

掌握这四大角色，我就真正理解了现代互联网“第三方登录”和“API 授权”背后的通用语言。