1. OAuth2 概述：协议发展、核心角色与授权码模式流程总览

1.1 OAuth2 协议发展历史

OAuth（开放授权）协议最初于 2007 年由 Twitter、Google 等社区成员起草，旨在解决第三方应用访问用户资源时的密码共享问题。OAuth 1.0（2007）引入了签名机制但实现复杂；OAuth 1.0a（2009）修复了会话固定攻击漏洞。2012 年，IETF 正式发布 OAuth 2.0 框架（RFC 6749），放弃了签名要求，改用 HTTPS 与 Bearer Token，大幅降低了客户端集成门槛，成为当今最广泛使用的授权协议。

1.2 核心角色

OAuth 2.0 定义了四个核心角色，它们之间的交互构成了整个授权体系：

• 资源所有者（Resource Owner） — 通常是用户，拥有对受保护资源的访问权限。例如：拥有 GitHub 仓库访问权的开发者。
• 客户端（Client） — 代表第三方应用，需要获取资源所有者的授权才能访问资源。例如：一个 CI/CD 工具需要读取用户的代码仓库。
• 授权服务器（Authorization Server） — 负责验证资源所有者身份并颁发授权码与访问令牌。例如：GitHub OAuth 端点 https://github.com/login/oauth/authorize。
• 资源服务器（Resource Server） — 托管受保护资源的服务器，使用访问令牌验证请求并返回资源。例如：GitHub API https://api.github.com/user/repos。

1.3 授权码模式流程总览

授权码模式（Authorization Code Grant）是 OAuth 2.0 中最完整、最安全的流程，适用于有后端服务器的客户端（如 Web 应用、移动 App 后端）。其核心思想是：客户端先获取一个临时授权码，再用授权码向授权服务器换取访问令牌，避免令牌直接暴露在用户代理（浏览器）中。

1.4 授权码模式详细步骤

1. 用户发起授权请求 — 用户在客户端（如 Web 应用）点击“使用 GitHub 登录”，客户端将用户重定向到授权服务器（GitHub）的授权端点，附带 client_id、redirect_uri、response_type=code 等参数。
2. 用户认证并同意 — 授权服务器验证用户身份（登录），并展示授权页面，询问用户是否允许客户端访问指定资源。用户点击“同意”。
3. 授权服务器返回授权码 — 授权服务器通过重定向将 授权码（authorization code） 发送到客户端指定的 redirect_uri。授权码有效期极短（通常 10 分钟），且只能使用一次。
4. 客户端用授权码换取令牌 — 客户端后端使用授权码、client_secret（或 PKCE 的 code_verifier）向授权服务器的令牌端点发起 POST 请求，获取 访问令牌（access token） 和可选的 刷新令牌（refresh token）。
5. 访问受保护资源 — 客户端在请求资源服务器 API 时，在 HTTP 头中携带 Authorization: Bearer <access_token>。资源服务器验证令牌的有效性与作用域，返回资源数据。

1.5 授权码模式与其他模式对比