OAuth 2.0 的安全升级版授权协议 OAuth 2.1 详解

OAuth 2.1 是对 OAuth 2.0 协议的一次重大更新，废弃了不安全的用法，整合了最新的安全实践，从而提高了协议的安全性和易用性。虽然“OAuth 2.1”从名称上看起来像是一个全新的版本，但实际上并非对 OAuth 2.0 的彻底的颠覆，其实是 OAuth 2.0 的最佳实践集合，整合了多年来社区反馈的最佳使用方式并做了必要的安全性改进。

OAuth 2.1 相比 OAuth 2.0 的安全性改进

OAuth 2.1 的核心目标是提升安全性，通过一系列的“减法”和“强制要求”，消除了 OAuth 2.0 中存在的安全隐患。以下是最关键的几个变化：

1. 强制要求使用 PKCE（Proof Key for Code Exchange）

在 OAuth 2.0 中，PKCE (RFC 7636) 是为无法安全存储客户端密钥的“公共客户端”（例如手机 App 和单页应用 SPA）设计的可选扩展。实践证明 PKCE 能有效防止授权码拦截攻击（Authorization Code Interception Attack）。

OAuth 2.1 将 PKCE 提升为对所有客户端（包括能够安全存储密钥的“机密客户端”，如后端服务器）在使用授权码流程时的强制要求。 这意味着任何类型的应用都必须通过使用 code_verifier 和 code_challenge 参数来增强授权码流程的安全性，确保了即使授权码在传输过程中被截获，攻击者也无法在没有 code_verifier 的情况下用它来换取访问令牌。

2. 废弃了隐式授权流程 (Implicit Grant)

隐式授权流程 (response_type=token) 曾被广泛应用于单页应用，因为能直接在浏览器前端通过重定向获得访问令牌（Access Token）。然而，这种方式存在严重的安全风险：

• 令牌泄露: 因为访问令牌直接暴露在 URL 中，容易通过浏览器历史、日志、Referer 头等途径泄露。

• 无法颁发刷新令牌 (Refresh Token): 导致用户需要频繁重新认证。

鉴于现代浏览器普遍支持跨域资源共享（CORS），并且授权码流程结合 PKCE 已能安全地服务于单页应用，所以 OAuth 2.1 完全废弃了隐式授权流程。单页应用现在必须使用带有 PKCE 的授权码流程。

3. 废弃“资源所有者密码凭证”流程 (Resource Owner Password Credentials Grant)

此流程 (grant_type=password) 允许客户端直接使用用户的用户名和密码来换取访问令牌。这种方式其实是违背了 OAuth 的核心理念——委托授权，让应用直接接触到了用户的核心凭证，带来了巨大的安全风险：

• 扩大了攻击面: 客户端需要安全地处理和存储用户密码。

• 不支持多因素认证 (MFA): 难以集成更高级的认证机制。

• 用户体验差: 用户被迫向第三方应用交出自己的密码。

因此，OAuth 2.1 彻底移除了密码凭证授权流程。推荐的替代方案是引导用户使用标准的授权码流程。

4. 精确匹配重定向 URI (Redirect URI)

在 OAuth 2.0 中，对重定向 URI 的匹配规则的要求较为宽松，允许部分匹配或使用通配符，这给“开放重定向”（Open Redirect）攻击留下了可乘之机。攻击者可能构造一个恶意的重定向 URI，诱导授权服务器将授权码或令牌发送到其控制的地址。

OAuth 2.1 要求授权服务器必须对客户端预先注册的重定向 URI 进行严格的字符串精确匹配。 这大大降低了因配置不当而导致的安全风险。

5. 禁止在 URL 查询参数中携带访问令牌

OAuth 2.0 允许将访问令牌作为 URL 查询参数传递。这种做法与隐式授权流程一样，极易导致令牌通过服务器日志、浏览器历史等方式泄露。

OAuth 2.1 明确禁止了这种用法。 访问令牌应始终通过安全的方式传输，首选的方式是放在 HTTP 请求的 Authorization 头中 (例如：Authorization: Bearer )。

6. 对刷新令牌 (Refresh Token) 提出更严格的要求

对于公共客户端，如果颁发了刷新令牌，OAuth 2.1 提出了更严格的安全要求，以限制其被盗用后的危害：

• 发送者约束 (Sender-Constrained): 通过 DPoP (Demonstration of Proof-of-Possession) 等机制，将刷新令牌与特定的客户端实例绑定。

• 一次性使用 (One-Time Use): 每次使用刷新令牌后，授权服务器都会颁发一个新的刷新令牌，并立即使旧的失效（即刷新令牌轮换 Refresh Token Rotation）。

OAuth 2.1 支持的授权流程

经过简化后，OAuth 2.1 主要推荐和支持以下两种授权流程：

• 授权码流程 (Authorization Code Grant) + PKCE: 这是最核心、最安全的流程，适用于所有类型的应用，包括 Web 应用、单页应用、移动应用等。

• 客户端凭证流程 (Client Credentials Grant): 适用于机器到机器（M2M）的通信场景，即客户端以自己的名义请求访问受保护的资源，不涉及最终用户的参与。

从 OAuth 2.0 到 2.1 的迁移要点

对于正在使用 OAuth 2.0 的开发者而言，迁移到 OAuth 2.1 需要注意以下几个方面：

• 全面启用 PKCE: 确保所有的授权码流程都使用了 PKCE。

• 停止使用隐式流程: 将所有使用 response_type=token 的地方改造为使用带有 PKCE 的授权码流程。

• 废弃密码凭证流程: 移除所有直接处理用户密码获取令牌的逻辑。

• 严格校验重定向 URI: 检查并确保授权服务器和客户端都使用精确的 URI 匹配。

• 规范令牌传递: 确保访问令牌仅通过 Authorization 请求头传递。

• 增强刷新令牌安全性: 为公共客户端实现刷新令牌轮换或发送者约束机制。

小结

OAuth 2.1 并非一个全新的协议，而是 OAuth 2.0 的最佳实践集合。通过移除过时和不安全的功能，将最佳实践固化为标准，极大地降低了开发者在实现授权功能时犯错的可能性。对于任何新建的应用，直接采用 OAuth 2.1 的规范无疑是最佳选择。对于现有系统，也应尽快向 OAuth 2.1 的要求靠拢，以构建一个更加稳固和安全的授权体系。