目录

一、什么是OAuth2？

二、重点：OAuth2 授权码模式（主流标准）

1. 模式特点

2. 完整交互流程（文字分步详解）

步骤 1：客户端引导用户跳转至授权服务器

步骤 2：用户在授权服务器登录 + 手动授权

步骤 3：授权服务器返回 授权码（Code）

步骤 4：客户端后端用 Code 换取令牌（核心安全点）

步骤 5：授权服务器校验并返回令牌

步骤 6：客户端使用 Access Token 访问资源服务器

步骤 7：资源服务器校验令牌并返回数据

步骤 8：Token 过期后使用 Refresh Token 续期（可选）

三、完整授权码模式时序流程

四、关键安全要点（面试 / 开发必记）

五、场景举例（通俗理解）

---

一、什么是OAuth2？

        OAuth 2.0 是目前主流的第三方授权协议，不是认证协议，核心作用：让第三方应用在不获取用户账号密码的前提下，有限、安全地访问用户在资源服务器上的资源。

核心角色（4 大必备角色）

1. 资源所有者（Resource Owner）：用户本人，拥有账号和数据，拥有授权权。
2. 客户端（Client）：第三方应用（比如小程序、网站、APP），想要访问用户数据。
3. 授权服务器（Authorization Server）：账号体系服务（如微信、QQ、抖音、企业登录中心），负责登录、鉴权、发授权码 / 令牌。
4. 资源服务器（Resource Server）：存放用户数据的服务，校验令牌并返回资源，通常和授权服务器同属一个平台。

核心术语

• 授权码（Authorization Code）：临时凭证，一次性、短期有效。
• Access Token（访问令牌）：客户端访问资源的核心凭证，短期有效。
• Refresh Token（刷新令牌）：长效凭证，用于 Access Token 过期后换新令牌，免重复登录。
• 重定向地址（Redirect URI）：授权服务器完成操作后，跳转回第三方应用的地址，提前在平台配置。

四种授权模式（常用区分）

1. 授权码模式（Authorization Code）：最安全、最常用，适用于 Web 网站、后端服务、APP（有服务端），优先推荐。
2. 简化模式（隐式模式 Implicit）：纯前端 SPA 页面，无后端，令牌直接返回前端，安全性弱。
3. 密码模式（Resource Owner Password）：客户端直接索要账号密码，仅信任内部应用使用，公网严禁使用。
4. 客户端模式（Client Credentials）：无用户参与，应用之间授权（如服务间调用）。

二、重点：OAuth2 授权码模式（主流标准）

1. 模式特点

• 分为两步获取令牌：先拿授权码 → 再用授权码换令牌
• 授权码仅在浏览器 + 授权服务器流转，令牌仅在后端服务之间流转
• 全程不泄露用户密码，安全性最高，绝大多数第三方登录（微信 / 支付宝 / 钉钉 / 开源平台）都用此模式

2. 完整交互流程（文字分步详解）

前置准备：第三方应用（客户端）提前在授权平台注册，获取 Client ID、Client Secret、备案合法 Redirect URI。

步骤 1：客户端引导用户跳转至授权服务器

用户在第三方应用点击「使用 XX 账号登录」。
客户端拼接授权请求 URL，参数包含：

• client_id：应用唯一标识
• response_type=code：指定使用授权码模式
• scope：申请的权限（如用户昵称、头像、手机号）
• redirect_uri：授权成功后的跳转地址
• state：随机字符串（防 CSRF 攻击，建议必带）

步骤 2：用户在授权服务器登录 + 手动授权

1. 用户输入账号密码，完成登录。
2. 页面展示授权弹窗：「是否允许【XX 应用】获取你的昵称、头像？」
3. 用户点击同意 / 拒绝。

步骤 3：授权服务器返回 授权码（Code）

• 若用户拒绝授权：跳转 redirect_uri，携带错误信息，流程终止。
• 若用户同意授权：授权服务器拼接 redirect_uri，在 URL 参数中带回 临时授权码 Code + 原 state。
• 浏览器自动跳回第三方应用的重定向地址，此时前端拿到 Code。

关键：Code 是短期一次性凭证，不能用来访问资源，仅用于下一步换令牌。

步骤 4：客户端后端用 Code 换取令牌（核心安全点）

第三方应用后端服务发起 HTTPS POST 请求 到授权服务器的令牌接口，提交参数：

• grant_type=authorization_code：指定授权类型
• code：上一步拿到的授权码
• client_id、client_secret：应用密钥（仅后端持有，前端不可暴露）
• redirect_uri：和第一步一致，用于校验

步骤 5：授权服务器校验并返回令牌

授权服务器校验：Code 合法性、ClientID/Secret、跳转地址。
校验通过后，返回 JSON 数据，包含：

• access_token：访问令牌（短期，比如 2 小时）
• token_type：令牌类型（一般为 Bearer）
• expires_in：令牌有效期（秒）
• refresh_token：刷新令牌（长期，用于续期）
• scope：实际授予的权限

步骤 6：客户端使用 Access Token 访问资源服务器

客户端后端携带 Access Token，请求资源服务器接口获取用户数据（头像、昵称、信息等）。

请求头格式示例：
Authorization: Bearer {access_token}

步骤 7：资源服务器校验令牌并返回数据

资源服务器校验 Token 有效性、权限。 校验通过 → 返回用户资源数据；校验失败 → 返回 401/403。

步骤 8：Token 过期后使用 Refresh Token 续期（可选）

Access Token 过期后，客户端后端使用 Refresh Token 再次请求令牌接口：
参数：grant_type=refresh_token + refresh_token + 客户端密钥
授权服务器返回新的 Access Token，用户无需重新登录。

三、完整授权码模式时序流程

四、关键安全要点（面试 / 开发必记）

• Client Secret 绝对不能暴露在前端，令牌交换必须由后端完成。
• state 参数必须使用随机值，防御 CSRF 跨站请求伪造。
• 所有交互必须使用 HTTPS，防止链路劫持、窃听。
• 授权码 Code 一次性使用、短时效，被盗影响有限。
• Access Token 短期有效，降低泄露风险；Refresh Token 需妥善保管。
• 严格校验 redirect_uri，防止恶意跳转钓鱼。

五、场景举例（通俗理解）

以「使用微信登录某网站」为例：

1. 你（资源所有者）在网站（客户端）点「微信登录」。
2. 网站跳转到微信登录页（授权服务器）。
3. 你扫码 / 输密码，同意授权。
4. 微信生成临时授权码，跳转回原网站。
5. 网站后端拿着授权码 + 自己的应用密钥，去找微信换 Access Token。
6. 后端用 Token 向微信资源接口拉取你的昵称、头像。
7. 网站展示你的微信信息，登录完成。