1. OAuth 2.0 概述：诞生背景、核心思想与四种授权模式
1.1 诞生背景：为什么需要 OAuth 2.0？
在 OAuth 诞生之前，第三方应用获取用户资源（如社交头像、邮件联系人）的唯一方式是直接获取用户的账号密码。这种“密码共享”模式存在严重的安全隐患：
- 密码泄露风险：第三方应用存储用户密码，一旦服务器被攻破，用户所有受保护资源全部暴露。
- 权限不可控：第三方应用获得的是用户账号的完整权限，无法限制其只能访问特定资源。
- 无法撤销：用户只能通过修改密码来收回第三方应用的访问权，但修改密码会导致所有其他应用同时失效。
- 责任边界模糊：资源服务器无法区分请求是来自用户本人还是第三方应用，审计和追责困难。
核心痛点：传统 HTTP 基本认证（Basic Auth）和 API Key 模式无法解决“委托授权”场景下的安全与可撤销问题。OAuth 2.0 正是为解决这一委托授权难题而诞生的开放标准（RFC 6749）。
1.2 核心思想：授权与资源分离
OAuth 2.0 的核心设计理念是将“授权”与“资源访问”解耦。它引入了一个独立的授权服务器（Authorization Server），专门负责颁发和验证访问令牌（Access Token），而资源服务器（Resource Server）只负责验证令牌并返回资源。整个流程围绕四个角色展开：
| 角色 | 英文名称 | 职责说明 |
|---|---|---|
| 资源所有者 | Resource Owner | 拥有受保护资源的实体，通常是用户本人。决定是否授权第三方应用访问其资源。 |
| 客户端 | Client | 需要访问用户资源的第三方应用，如 Web 应用、移动 App、后端服务。 |
| 授权服务器 | Authorization Server | 负责验证资源所有者身份，并向客户端颁发访问令牌的核心组件。 |
| 资源服务器 | Resource Server | 托管受保护资源的服务器，通过验证访问令牌来决定是否返回资源。 |
OAuth 2.0 的核心思想可以概括为：客户端通过授权服务器获取令牌，再凭令牌向资源服务器请求资源，全程不接触用户密码。
1.3 四种授权模式简介
OAuth 2.0 定义了四种授权模式（Grant Types），以适应不同客户端类型和安全需求。每种模式在令牌获取流程、安全级别和适用场景上存在显著差异。
| 授权模式 | 英文名称 | 核心流程 | 典型场景 | 安全级别 |
|---|---|---|---|---|
| 授权码模式 | Authorization Code | 用户授权 → 授权码 → 令牌 | Web 服务端应用（有后端） | ★★★★★ |
| 隐式模式 | Implicit | 用户授权 → 直接返回令牌 | 纯前端 SPA（已不推荐） | ★★★☆☆ |
| 密码模式 | Resource Owner Password Credentials | 用户提供密码 → 令牌 | 高度信任的第一方应用 | ★★☆☆☆ |
| 客户端凭证模式 | Client Credentials | 客户端凭证 → 令牌 | 服务间通信、后端 API | ★★★★☆ |
课程聚焦：本课程将重点深入讲解客户端凭证模式（Client Credentials Grant），这是服务端架构中最常用的机器对机器（M2M）授权方式，也是构建后端权限矩阵的基础。
1.4 授权模式对比与选择依据
选择哪种授权模式，主要取决于以下三个因素：
- 客户端类型：是否有能力安全存储客户端密钥（confidential client vs. public client）。
- 资源所有者交互：是否需要用户参与授权流程。
- 安全需求：令牌泄露的风险承受能力。
1.5 关键术语与概念澄清
| 术语 | 说明 | 常见误区 |
|---|---|---|
| Access Token | 访问令牌，客户端用于访问资源服务器的凭证 | ≠ 用户密码，≠ Session ID |
| Refresh Token | 刷新令牌，用于在 Access Token 过期后获取新的令牌 | 客户端凭证模式通常不颁发 Refresh Token |
| Scope | 作用域，定义令牌允许访问的资源范围 | 不是权限矩阵，只是粗粒度的权限分组 |
| Client ID / Secret | 客户端标识和密钥，用于客户端身份认证 | Client Secret 必须安全存储，不能泄露 |
| Grant Type | 授权类型，定义令牌获取的具体流程 | 不同 Grant Type 的安全假设完全不同 |
安全提醒：OAuth 2.0 本身只定义了授权框架，并不提供传输层安全。所有令牌交换必须在 HTTPS 下进行，否则令牌可能被中间人攻击截获。此外，客户端凭证模式中，Client Secret 的泄露等同于令牌泄露，务必使用环境变量或密钥管理服务（KMS）进行存储。
1.6 本章小结
- OAuth 2.0 解决了密码共享带来的安全风险，实现了授权与资源访问的分离。
- 核心四角色：资源所有者、客户端、授权服务器、资源服务器。
- 四种授权模式各有适用场景，客户端凭证模式是服务间通信的首选。
- 从下一章开始，我们将深入客户端凭证模式的技术细节，包括令牌请求、验证、权限矩阵集成以及安全最佳实践。