OAuth2.0 详解+案例

角色名称	英文全称	核心职责	举例
资源所有者	Resource Owner	拥有资源的用户，能授予第三方应用访问权限	使用 “微信登录某购物小程序” 的你
客户端	Client	需要访问用户资源的第三方应用	上述的 “购物小程序”
授权服务器	Authorization Server	资源所有者平台（如微信）提供的服务器，负责验证用户身份、发放 “授权凭证”	微信的授权服务器（处理登录授权请求、生成 token）
资源服务器	Resource Server	存储用户资源的服务器，仅接受 “授权凭证”（如 token）请求资源	微信的用户信息服务器（存储你的头像、昵称，需 token 才能读取）

二、OAuth 2.0 的核心流程（简化版）

OAuth 2.0 的流程本质是 “客户端通过授权服务器获取授权凭证，再用凭证向资源服务器请求资源”，核心步骤可简化为 4 步：

客户端请求授权：用户在客户端（如购物小程序）点击 “微信登录”，客户端跳转至授权服务器（微信授权页），请求用户授予 “读取头像昵称” 的权限。
用户授予授权：用户在授权服务器页面确认授权（如点击 “允许”）。
授权服务器发放凭证：授权服务器验证用户身份后，向客户端发放 “授权凭证”（通常是 Access Token）。
客户端请求资源：客户端携带 Access Token 向资源服务器（微信用户信息接口）发起请求，资源服务器验证 Token 有效后，返回用户头像、昵称等资源。

三、OAuth 2.0 的 4 种核心授权模式

OAuth 2.0 并非单一流程，而是根据客户端的安全级别（如是否有服务器、是否能存储密钥）设计了 4 种授权模式，最常用的是前两种：

1. 授权码模式（Authorization Code Flow）—— 最安全、最常用

适用场景：有后端服务器的客户端（如传统网站、APP 后端），因为客户端能安全存储 “客户端密钥”（Client Secret），避免密钥泄露。核心特点：通过 “授权码”（Authorization Code）间接获取 Access Token，而非直接获取，安全性最高。典型流程：

客户端（网站后端）跳转用户至授权服务器，携带 “客户端 ID、请求权限、回调地址”；
用户授权后，授权服务器跳转回 “回调地址”，并携带授权码；
客户端后端用 “授权码 + 客户端密钥” 向授权服务器请求 Access Token；
授权服务器验证通过后，返回 Access Token（可选附带 Refresh Token）。举例：GitHub 第三方登录、支付宝开放平台接口调用。

2. 简化模式（Implicit Flow）—— 无后端客户端专用

适用场景：无后端的纯前端应用（如 Vue/React 单页应用、前端静态页面），无法安全存储 “客户端密钥”。核心特点：不通过 “授权码”，直接返回 Access Token，但不返回 Refresh Token（因前端存储 Token 风险较高）。典型流程：

客户端（前端）跳转用户至授权服务器，携带 “客户端 ID、请求权限、回调地址”；
用户授权后，授权服务器直接将 Access Token 拼接在 “回调地址” 的 URL 中，返回给客户端；
客户端从 URL 中提取 Access Token，用于请求资源服务器。风险提示：Token 暴露在 URL 中，可能被日志、浏览器历史记录泄露，需搭配 HTTPS 和短期 Token 降低风险。

3. 密码模式（Resource Owner Password Credentials Flow）—— 高信任场景专用

适用场景：客户端与资源所有者平台高度信任（如平台自家的 APP），用户愿意向客户端提供账号密码。核心特点：用户直接向客户端提供账号密码，客户端用 “用户账号密码 + 客户端 ID” 向授权服务器请求 Access Token。风险提示：客户端获取了用户的原始密码，违背 OAuth “不共享密码” 的核心设计，仅在极端信任场景使用（如企业内部系统）。举例：某公司自家 APP 用 “员工企业邮箱账号密码” 获取内部系统的访问权限。

4. 客户端模式（Client Credentials Flow）—— 无用户场景专用

适用场景：客户端自身需要访问资源服务器的 “公共资源”（无需用户授权），如客户端获取平台的公共 API 数据（如天气、新闻列表）。核心特点：无用户参与，客户端直接用 “客户端 ID + 客户端密钥” 向授权服务器请求 Access Token，Token 仅代表 “客户端身份”，不关联用户。举例：某天气 APP 用自身的 “客户端密钥” 向天气平台请求全国天气数据。