1. OAuth2.0 概述
1.1 OAuth2.0 是什么
OAuth2.0 是一种授权框架，它允许第三方应用（客户端）在不获取用户密码的情况下，通过一个令牌（Token）来访问用户存储在资源服务器上的受保护资源。它本质上是将“用户身份”与“应用权限”解耦，让授权行为标准化、安全化。
OAuth2.0 不是一种协议，而是一个框架，它定义了四种授权模式，以适应不同的应用场景（如 Web 应用、移动端、服务端到服务端等）。
核心思想：用户授权第三方应用访问其资源，但不需要将密码交给第三方。授权服务器颁发一个限时、限范围的令牌，资源服务器只认令牌不认密码。
1.2 为什么需要 OAuth2.0
在传统身份验证模式中，第三方应用直接使用用户的用户名和密码访问资源，存在严重的安全隐患：
- 密码泄露风险：第三方应用必须存储用户的明文密码，一旦其服务器被攻破，用户密码将全部泄露。
- 权限不可控：第三方应用获得的是用户账号的完全访问权限，无法限制其只能访问特定资源（如只能读取头像，不能发帖）。
- 无法撤销授权：用户一旦将密码交给第三方，除非修改密码，否则无法单独撤销该应用的访问权限。
- 适用范围窄：密码认证无法很好地支持移动端、单页应用（SPA）等无状态或跨域场景。
OAuth2.0 通过引入令牌（Token）和授权码（Authorization Code）等机制，完美解决了上述问题：
| 对比维度 | 传统密码认证 | OAuth2.0 授权 |
|---|---|---|
| 凭证类型 | 用户名 + 密码 | 访问令牌（Access Token） |
| 凭证存储 | 第三方应用存储密码 | 第三方应用存储令牌 |
| 权限粒度 | 全权访问 | 可限定范围（Scope） |
| 撤销方式 | 修改密码（影响所有应用） | 单独撤销令牌或刷新令牌 |
| 适用场景 | 第一方应用 | 第三方应用、微服务、开放API |
1.3 OAuth2.0 的核心角色
OAuth2.0 定义了四个核心角色，它们之间的交互构成了整个授权流程的基础。理解这四个角色是掌握 OAuth2.0 的关键。
- 资源所有者（Resource Owner）：通常是用户，拥有受保护资源的实体。它能够授权客户端访问其资源。
- 客户端（Client）：代表第三方应用，它需要访问资源所有者的受保护资源。客户端在授权之前，必须先向授权服务器注册。
- 授权服务器（Authorization Server）：负责验证资源所有者的身份，并在获得授权后向客户端颁发访问令牌。它是整个授权流程的核心枢纽。
- 资源服务器（Resource Server）：托管受保护资源的服务器。它使用访问令牌来验证客户端的请求，并返回相应的资源。
关键关系：授权服务器和资源服务器可以是同一台服务器，也可以是不同的服务器。在大型系统中，它们通常是分离的，以实现职责解耦和水平扩展。
1.4 角色交互流程概览
为了更清晰地展示这四个角色如何协同工作，下面是一个典型的授权码模式（Authorization Code Grant）的交互流程。这是 OAuth2.0 中最安全、最常用的模式。
注意：在实际开发中，授权服务器和资源服务器通常是两个独立的服务。授权服务器负责颁发和验证令牌，资源服务器只负责验证令牌的有效性并返回资源。这种分离设计是构建高可用、可扩展微服务架构的基础。
1.5 角色职责总结
| 角色 | 核心职责 | 典型实现 |
|---|---|---|
| 资源所有者 | 确认授权、管理授权范围 | 用户浏览器、移动端用户界面 |
| 客户端 | 引导用户授权、获取令牌、携带令牌访问资源 | Web 应用（Spring Boot）、移动 App（Android/iOS）、SPA（Vue/React） |
| 授权服务器 | 验证用户身份、颁发令牌、刷新令牌、撤销令牌 | Spring Authorization Server、Keycloak、Auth0、自建服务 |
| 资源服务器 | 验证令牌、返回受保护资源 | Spring Boot Resource Server、API 网关（Kong、Zuul） |