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”时，我本人就是资源所有者。

🔑 职责

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

🌰 典型示例

场景	资源所有者
微信小程序读取我的头像和昵称	我（微信用户）
一个记账 App 访问我的支付宝交易记录	我（支付宝用户）
企业内部系统调用 HR 系统的员工信息	员工本人（或管理员代表）

⚠️ 注意：虽然 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

🌰 典型示例

场景	资源服务器
GitHub API 提供用户仓库列表	api.github.com
微信开放平台提供用户基本信息	api.weixin.qq.com/sns/userinfo
我公司内部的订单服务 API	order-service.yourcompany.com

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

---

三、客户端（Client）

✅ 定义

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

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

🔑 职责

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

🌰 典型示例

客户端类型	示例
Web 应用（有后端）	一个使用“GitHub 登录”的博客网站
单页应用（SPA）	React/Vue 前端应用（需配合 PKCE）
移动 App	微信、抖音等调用第三方登录
后端服务（M2M）	支付服务调用风控服务的内部 API

⚠️ 客户端必须提前在授权服务器注册（提供 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 校验或公钥分发接口

🌰 典型示例

类型	示例
公共授权服务器	Google Identity Platform、Auth0、Okta、微信开放平台
自建授权服务器	使用 Spring Authorization Server、Keycloak、ORY Hydra 搭建的内部系统

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

---

 

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

 

✅ 关键点：

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

---

六、常见误区澄清

误区	正确理解
“授权服务器 = 身份认证服务器”	授权服务器主要做授权；若需返回用户身份信息（如姓名、邮箱），需结合 OpenID Connect（OIDC）
“资源服务器要验证用户密码”	❌ 资源服务器只验证 Token，不处理密码
“客户端可以随便拿 Token”	❌ 客户端必须先注册，且需通过授权流程（用户同意或客户端凭证）
“Access Token 是用户身份证明”	不完全对：它代表授权凭证，不是身份凭证（除非是 OIDC 的 ID Token）

---

七、总结

角色	核心问题	关键特征	安全要求
资源所有者	“谁的数据被访问？”	通常是用户	需明确授权（知情同意）
资源服务器	“谁能访问我的 API？”	验证 Token，返回数据	必须严格校验 Token 有效性
客户端	“我想代表用户访问数据”	发起请求，持有 Token	必须安全存储 Token 和 client_secret
授权服务器	“我来发通行证”	认证用户，签发 Token	最高安全级别，防钓鱼、CSRF、重放攻击

---

💡 最后建议

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

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