OAuth 2.0

什么是 OAuth 2.0

OAuth 2.0 是一种授权框架，允许第三方应用在不共享用户密码的情况下获得对用户资源的有限访问权限。在 RFC 6749 中标准化。

常见的例子是"使用 Google 登录""使用 GitHub 登录"等社交登录。在这种情况下，无需将 Google 密码告知要使用的服务，即可授权其访问 Google 持有的个人资料信息 (姓名、邮箱地址等)。

重要的是，OAuth 2.0 是"授权 (Authorization)"框架，而非"认证 (Authentication)"协议。需要认证功能时，使用构建在 OAuth 2.0 之上的 OpenID Connect (OIDC)。大多数单点登录基于 OIDC。

OAuth 2.0 的角色与流程

OAuth 2.0 涉及四个角色。

• 资源所有者：数据的所有者 (通常是用户本人)
• 客户端：想要访问用户数据的应用
• 授权服务器：发放访问令牌的服务器 (如 Google 的授权端点)
• 资源服务器：持有用户数据的服务器 (如 Google 的 API 服务器)

最常见的 Authorization Code Flow 流程如下。

1. 用户点击客户端应用的"使用 Google 登录"按钮
2. 客户端将用户重定向到 Google 的授权端点
3. 用户在 Google 登录页面认证并同意访问权限
4. Google 将授权码 (临时代码) 返回给客户端
5. 客户端将授权码交换为访问令牌
6. 客户端使用访问令牌从 Google API 获取用户信息

通过这一机制，客户端应用完全不知道用户的 Google 密码，即可在许可范围内访问数据。

通过作用域进行访问控制

OAuth 2.0 的重要概念是"作用域"。作用域定义了授予访问令牌的权限范围。

例如，Google 的 OAuth 2.0 定义了以下作用域。

• profile：读取姓名和头像
• email：读取邮箱地址
• https://www.googleapis.com/auth/drive.readonly：Google Drive 只读访问
• https://www.googleapis.com/auth/calendar：Google 日历读写访问

用户在同意页面上确认的就是这些作用域列表。如果应用请求过于广泛的作用域 (如日历应用请求访问通讯录)，可能存在不必要的数据收集。根据数据最小化原则，请确认应用是否仅请求了最小必要的作用域。

OAuth 2.0 的安全注意事项

以下是用户安全使用 OAuth 2.0 应了解的要点。

• 务必确认同意页面：确认应用请求的权限 (作用域)，不要同意请求不必要广泛权限的应用
• 定期审查应用关联：在 Google、GitHub 等账户设置中确认已关联的第三方应用，撤销不再使用的应用的访问权限
• PKCE (Proof Key for Code Exchange) 的重要性：移动应用和 SPA (单页应用) 中，防止授权码拦截攻击的 PKCE 扩展是必须的。OAuth 2.1 计划将 PKCE 设为所有客户端的必需项
• CSRF 防护：使用 state 参数验证授权请求和回调的对应关系。防止攻击者让用户使用攻击者准备的授权码
• 严格的重定向 URI 验证：授权服务器应仅允许已注册的重定向 URI，防止开放重定向漏洞

常见误解

OAuth 2.0 是用于登录 (认证) 的协议

OAuth 2.0 是授权 (资源访问许可) 框架，而非认证 (用户身份验证) 协议。认证使用构建在 OAuth 2.0 之上的 OpenID Connect (OIDC)。"使用 Google 登录"准确来说是 OIDC 认证。

使用社交登录就不会有密码泄露风险

社交登录消除了各服务的单独密码需求，但如果 Google 或 GitHub 账户被入侵，所有关联服务都会受到影响。务必在 SSO 账户上设置双因素认证，并定期审查应用关联。

相关术语