OAuth 2.0 与 OAuth 2.1 对比

OAuth 2.0 和 OAuth 1.0 的核心区别在于协议的设计理念和安全性，而 OAuth 2.1 则是 OAuth 2.0 的改进版本，主要目的是修复 OAuth 2.0 的已知安全漏洞，并整合近年来提出的最佳实践。以下是两者的关键对比：

1. 安全性增强

OAuth 2.0

• 授权码模式（Authorization Code Flow）：允许公共客户端（如单页应用或移动应用）在未使用 PKCE（Proof Key for Code Exchange）的情况下使用授权码流程，存在授权码截获漏洞。
• 隐式授权模式（Implicit Flow）：直接将访问令牌（Access Token）返回给前端（通过 URL 片段），容易因 Token 泄漏导致安全风险。
• Bearer Token 默认使用：未强制要求对访问令牌进行加密或签名，依赖传输层安全（如 HTTPS），存在中间人攻击风险。

OAuth 2.1

• 强制使用 PKCE：所有使用授权码模式的客户端（包括公共客户端和机密客户端）必须使用 PKCE，防止授权码截获攻击（如 Authorization Code Injection）。
• 废除隐式授权模式：不再推荐隐式授权流程，改为优先使用授权码模式（结合 PKCE）。
• 更严格的客户端认证：所有非公共客户端（机密客户端，如服务器端应用）必须进行客户端认证（如 Client ID + Secret 或证书）。
• 令牌绑定（Token Binding）：建议对令牌进行加密或签名，降低令牌泄漏风险。

2. 废弃或修改的流程

OAuth 2.0

• 隐式授权模式（Implicit Flow）：允许，但存在安全隐患。
• 资源所有者密码模式（Password Grant）：允许直接传递用户名/密码，不推荐但未强制废除。

OAuth 2.1

• 废除隐式授权模式：完全移除隐式授权流程。
• 废除密码模式：不再允许资源所有者密码模式（ROPC）。
• 仅保留两种核心流程：
  1. 授权码模式（Authorization Code Flow + PKCE）：用于所有客户端（公共和机密）。
  2. 客户端凭证模式（Client Credentials Flow）：用于服务端到服务端的认证。

3. 新增规范整合

• OAuth 2.0：基于 RFC 6749 和 RFC 6750，但未整合后续的安全扩展（如 PKCE）。
• OAuth 2.1：
  • 整合 RFC 7636（PKCE）。
  • 整合 RFC 8252（针对移动和单页应用的最佳实践）。
  • 整合 RFC 8414（授权服务器元数据）。
  • 移除过时或易被滥用的功能（如密码模式和隐式模式）。

4. 令牌生命周期

• OAuth 2.0：未严格要求刷新令牌（Refresh Token）的使用方式，部分实现可能暴露刷新令牌。
• OAuth 2.1：
  • 限制刷新令牌的范围：刷新令牌只能用于获取新的访问令牌，不能直接访问资源。
  • 强制要求刷新令牌绑定到客户端（防止跨客户端滥用）。

5. 对开发者的影响

• OAuth 2.0：
  • 灵活性高，但需要开发者自行实现安全最佳实践（如 PKCE）。
  • 需自行防范常见攻击（如 CSRF、Token 泄漏）。
• OAuth 2.1：
  • 更严格的安全约束，简化开发者的安全设计负担。
  • 强制使用 PKCE 和客户端认证，要求代码升级。

总结对比表

何时使用？

• OAuth 2.0：仅适用于旧系统维护，或需要兼容不支持 OAuth 2.1 的遗留服务。
• OAuth 2.1：推荐用于所有新项目，尤其是需要高安全性的场景（如金融、医疗应用）。

迁移建议

1. 移除隐式授权和密码模式。
2. 为所有客户端启用 PKCE。
3. 强制机密客户端进行认证（如使用 Client Secret）。
4. 升级授权服务器（如 Keycloak、Auth0、Okta）到支持 OAuth 2.1 的版本。

OAuth 2.1 本质上是 OAuth 2.0 的安全加固版本，旨在简化协议复杂性并修复已知漏洞，是未来趋势。