📚 课程目录第1章 OAuth2基础概念

1. OAuth2 基础概念

1.1 OAuth2 是什么

OAuth2（Open Authorization 2.0）是一个授权框架，它允许第三方应用在用户（资源所有者）授权的前提下，获取对用户存储在另一服务上的资源的有限访问权限，而无需向第三方应用暴露用户的登录凭据（如密码）。

OAuth2 的核心思想是授权与认证分离：认证确认“你是谁”，授权决定“你能做什么”。OAuth2 只负责授权，不处理用户身份认证（通常由 OpenID Connect 补充）。

关键理解：OAuth2 不是身份认证协议，而是一个委托授权协议。它通过发放访问令牌（Access Token）来替代密码，实现安全、可控的资源访问。

1.2 为什么需要 OAuth2

在 OAuth2 出现之前，第三方应用获取用户资源通常采用以下两种方式，都存在严重的安全隐患：

方式	描述	安全风险
密码共享	第三方应用直接存储用户的用户名和密码	密码泄露、无法控制访问范围、无法撤销单个应用权限
万能令牌	服务商为第三方应用颁发一个长期有效的 API Key	无法区分用户、无法实现细粒度授权、Key 泄露影响所有用户

OAuth2 解决了以下核心问题：

密码不泄露：第三方应用永远看不到用户的密码，授权服务器直接颁发令牌。
细粒度授权：用户可以指定第三方应用只能访问特定资源（如只读相册、仅查看联系人）。
权限可撤销：用户或授权服务器可以随时撤销某个应用的令牌，不影响其他应用。
令牌生命周期管理：令牌可以设置有效期、刷新机制，降低长期泄露风险。
标准化互操作：不同服务商（Google、GitHub、等）遵循统一协议，降低集成成本。

  合规视角：GDPR、个人信息保护法等法规要求应用最小化收集用户数据。OAuth2 的细粒度授权机制是实现“数据最小化”原则的关键技术手段，也是合规审计中的重点检查项。

1.3 OAuth2 的核心角色

OAuth2 协议定义了四个核心角色，它们之间的交互构成了授权流程的基础：

角色	英文名称	职责描述	典型示例
资源所有者	Resource Owner	拥有受保护资源的实体，通常是用户本人。它能够授权客户端访问其资源。	使用登录某网站的用户
客户端	Client	代表资源所有者请求访问受保护资源的第三方应用。它需要获得授权才能获取令牌。	第三方网站、移动 App、桌面应用
授权服务器	Authorization Server	负责验证资源所有者身份、获取授权、并向客户端颁发访问令牌的服务器。	OAuth2 授权服务、Google OAuth 2.0 端点
资源服务器	Resource Server	托管受保护资源的服务器，它接收并验证访问令牌，根据令牌的权限范围提供资源。	用户信息 API、Google Drive API

常见误区：授权服务器和资源服务器可以是同一台物理服务器，但在逻辑上是两个独立角色。在大型系统中，它们通常分离部署以提升安全性和扩展性。

1.4 核心角色交互流程

下图展示了 OAuth2 授权流程中四个核心角色的基本交互关系：

1.5 角色关系与权限边界

从权限合规的角度理解这四个角色，关键在于明确权限边界：

资源所有者是权限的源头，只有它才能决定“谁可以访问我的什么资源”。
客户端是权限的请求者，它必须明确声明需要哪些权限（scope），且不能超出授权范围。
授权服务器是权限的颁发者，它负责验证用户身份、确认授权意图、生成令牌并绑定权限范围。
资源服务器是权限的执行者，它必须严格验证每个请求的令牌是否有效、是否在授权范围内。

  合规审计要点：在审计 OAuth2 实现时，需要检查以下边界是否清晰：

  • 授权服务器是否强制用户确认授权范围（scope）？

  • 资源服务器是否对每个 API 请求都验证令牌的 scope？

  • 客户端是否存储了超出授权范围的令牌？

  • 令牌撤销后，资源服务器是否立即拒绝该令牌的访问？

1.6 本章小结

OAuth2 是一个委托授权框架，通过引入授权服务器和令牌机制，解决了密码共享和万能令牌的安全问题。四个核心角色——资源所有者、客户端、授权服务器、资源服务器——各司其职，共同构建了安全、可控、可审计的授权体系。理解这些基础概念是后续学习授权模式、令牌处理、合规边界验证的基石。