OAuth 2.1

OAuth 2.1 是一项正在进行中的工作，旨在整合和简化 OAuth 2.0 中最常用的功能。

自2012年OAuth 2.0（RFC 6749）首次发布以来，陆续有新的RFC发布，这些RFC对核心规范进行了功能上的增删，包括《原生应用的OAuth 2.0》（RFC 8252）、《代码交换证明密钥》（RFC 7636）、《基于浏览器的应用的OAuth》以及《OAuth 2.0安全最佳实践》。

OAuth 2.1整合了后续规范中发布的变更，以简化核心文档，并废弃了一些被认为不安全的流程（如隐式授权）。

与OAuth 2.0的主要区别

1. 所有使用授权码流程的OAuth客户端必须启用PKCE
   • 变更点：PKCE（代码交换证明密钥）从原本仅建议（特别是移动/原生应用使用）变为强制要求，适用范围扩展至所有采用授权码流程的客户端（包括Web应用）。
   • 原因：有效防御授权码拦截攻击。即使攻击者通过恶意软件或共享设备窃取授权code，若缺少合法客户端生成的code_verifier，仍无法兑换令牌。此举在客户端密钥泄露时仍能提供保护。OAuth 2.0仅对公开客户端建议使用PKCE。
2. 重定向URI必须严格精确匹配
   • 变更点：授权服务器必须对注册的重定向URI与请求中的redirect_uri参数进行完全一致的大小写敏感字符串比对，禁止子域名匹配、路径追加或忽略大小写等宽松规则。
   • 原因：杜绝开放重定向攻击。若允许模糊匹配，攻击者可构造相似域名（如https://client.com.attacker.com）或路径（如https://client.com/evil）窃取令牌。精确匹配确保令牌仅返回至预先注册的可信端点。
3. 隐式授权模式（response_type=token）被移除
   • 变更点：直接将访问令牌返回到URL片段中的隐式流程从核心规范中删除。
   • 原因：该模式存在严重安全隐患——令牌会暴露于浏览器历史记录、服务器日志（通过Referer头）且易遭泄漏。替代方案是采用PKCE加固的授权码流程，仅通过code在后端兑换令牌。OAuth 2.0已弃用此模式，OAuth 2.1彻底移除。
4. 资源所有者密码凭证模式被移除
   • 变更点：允许客户端直接收集用户账号密码并发送至授权服务器兑换令牌的流程从核心规范中删除。
   • 原因：该模式极不安全——诱导用户向第三方应用输入密码（增加钓鱼风险）、密码可能被客户端留存，且违背OAuth"无需共享密码即可授权"的核心原则。现代替代方案是结合PKCE的授权码流程。OAuth 2.0已不推荐，OAuth 2.1彻底移除。
5. 禁止在URI查询字符串中使用承载令牌
   • 变更点：明确禁止客户端在URL查询参数（如?access_token=...）中传递Bearer令牌。
   • 原因：URL常被服务器、代理或浏览器记录。查询字符串中的令牌可能长期留存于日志，导致未授权访问。规范要求令牌必须通过Authorization头（Bearer <token>）或（谨慎使用的）POST正文传递。OAuth 2.0建议避免，OAuth 2.1明文禁止。
6. 公开客户端的刷新令牌必须满足发送方约束或单次使用
   • 变更点：颁发给公开客户端（无法安全存储密钥的应用，如移动/原生应用或SPA）的刷新令牌必须满足以下任一条件：
     • 发送方约束：通过DPoP（持有证明演示）或mTLS等机制绑定至特定客户端实例，使用时需验证密钥所有权。
     • 单次使用：每次刷新后立即失效，仅能兑换新访问令牌（可选包含新刷新令牌）。
   • 原因：大幅降低刷新令牌被盗的影响。若公开客户端的刷新令牌被窃（如通过恶意软件），攻击者无法在其他设备使用。发送方约束要求密钥验证，单次使用则缩短攻击窗口。OAuth 2.0对此要求较弱。
7. 简化客户端类型定义
   • 变更点：公开客户端与机密客户端的区分更简洁：
     • 机密客户端：能安全保密其凭证（如密钥或私钥），典型如服务端Web应用。
     • 公开客户端：无法保密凭证（如浏览器应用或移动应用），本质上不具备有效的静态密钥。
   • 原因：明确安全预期。定义核心聚焦于客户端技术层面保护密钥的能力。OAuth 2.0的定义较复杂（如涉及"客户端认证"），易导致实现混淆。简化后直接关联如刷新令牌等安全要求（见第6点）。

总结

OAuth 2.1整合了OAuth 2.0多年实践中的安全最佳方案，核心改进包括：

1. 剔除不安全流程：移除隐式和密码模式
2. 强制关键防护：全面要求PKCE
3. 强化校验机制：严格执行重定向URI精确匹配
4. 降低令牌泄漏风险：禁用URL传令牌
5. 加固刷新令牌：对公开客户端施加严格限制
6. 明晰客户端安全：简化定义以聚焦密钥保护能力

这些变更使OAuth 2.1默认具备远高于OAuth 2.0的安全性，有效应对常见漏洞与攻击向量。新实现应直接采用OAuth 2.1规范。

举例讲解

我们用一个大家熟悉的场景—— “游乐园” 来形象地理解 OAuth 2.0/2.1 中授权服务器 (AS)、身份提供者 (IdP)、客户端 (Client) 和资源服务器 (Resource Server) 的关系和协作：

场景设定：

1. 你 (用户/资源拥有者)： 想去一个大型游乐园（比如叫“欢乐世界”）玩。
2. 第三方 App (客户端)： 一个叫“畅游助手”的手机App。它承诺可以帮你预订“欢乐世界”里的热门项目（比如过山车、摩天轮）、查看实时排队时间、甚至购买快速通行证。但它本身不是“欢乐世界”官方的东西。
3. 欢乐世界售票处 & 身份管理处 (授权服务器 AS + 身份提供者 IdP)：
   • 售票处窗口 (授权服务器 AS 的主要功能)：
     • 负责售票（发放令牌）：发放允许你玩项目的“游玩门票”（访问令牌 Access Token）和“续票凭证”（刷新令牌 Refresh Token）。
     • 检查App资质（客户端认证）：确认“畅游助手”这个App是经过他们审核、允许接入的合法合作伙伴（有合法的Client ID和Secret）。
     • 征得你的同意（用户授权）：当你第一次通过App连接时，会弹出一个窗口问你：“’畅游助手’App想获取你的基本资料（姓名、头像）并帮你预订项目，你同意吗？” 这个窗口本质上是售票处在征询你的意见。
   • 入园闸机 & 身份信息库 (身份提供者 IdP 的主要功能)：
     • 验票入园（用户认证）：你入园时，闸机（或工作人员）要验证你是你！这通常是通过扫描你的官方电子门票、年卡或者刷脸/指纹（对应用户名密码/MFA）来完成。这一步确认了“你是谁”。
     • 管理你的身份档案（身份信息管理）：“欢乐世界”内部有一个数据库，记录着所有注册会员的真实身份信息（姓名、照片、会员号、购买记录等）。这就是你的核心身份档案。
   • 重要提示： 在“欢乐世界”这个例子里，“售票处”和“入园闸机/身份信息库”虽然物理位置可能不同，但都属于“欢乐世界”官方运营体系，紧密集成。这对应现实中AS和IdP通常是同一个服务或深度集成。
4. 欢乐世界里的游乐项目 (资源服务器 Resource Server)： 比如过山车“极速飞龙”、摩天轮“星空之眼”。它们只认“欢乐世界”官方发放的、有效的“游玩门票”（访问令牌）。它们不关心你是通过什么App买的票，只关心票是不是真的、有没有权限玩本项目（比如你的票是否包含该项目或者有快速通行证）。

整个流程（对应授权码流程）：

1. 你想用“畅游助手”App订“极速飞龙” (用户发起请求)： 你打开“畅游助手”App，点击“预订极速飞龙”。
2. App把你带到“欢乐世界”售票处 (重定向到授权端点)： App弹出一个窗口（或者跳转到浏览器），把你带到“欢乐世界”官方售票处的特定窗口（AS的/authorize端点）。App告诉售票员：“这是我的证件（Client ID），我想帮这位游客（指你）订‘极速飞龙’，订成功后请把凭证发回给我的办公室（redirect_uri）。”
3. 售票处检查App并让你验明正身 (AS处理请求，触发IdP认证)：
   • 售票员先检查“畅游助手”的证件（Client ID）是否有效、登记在册（客户端认证）。
   • 然后售票员对你说：“要帮你订票，我需要先确认你是我们‘欢乐世界’的合法游客。请去那边的闸机刷一下你的年卡/门票验明身份！” (AS要求用户认证)
4. 你到闸机验票/刷脸 (用户认证 - IdP工作)： 你走到入园闸机（IdP），刷了你的年卡或者进行了人脸识别。闸机系统（IdP）验证通过，确认了“你是你” (用户认证成功)，并将这个成功信息（“用户123456已验证通过”）通知回售票处 (AS)。
5. 售票处征询你的同意 (用户授权 - AS工作)： 你回到售票窗口。售票员（AS）现在知道你是谁了，然后问你：“‘畅游助手’App想帮你预订‘极速飞龙’，并且需要知道你的名字和头像来显示预订信息。你同意吗？” (用户授权界面)。你点击“同意”。
6. 售票处给App一张“兑换券” (颁发授权码)： 售票员（AS）没有直接给你票，而是写了一张“兑换券”（授权码 Authorization Code），并告诉App：“拿着这张兑换券，带上你的正式证件（Client Secret），去我们后台的‘令牌办公室’（/token 端点）换真正的票吧。” 同时把你（用户的浏览器）送回了“畅游助手”App。
7. App后台兑换“真门票” (交换令牌 - 客户端到令牌端点)： “畅游助手”App的后台服务器，拿着“兑换券”（授权码）和自己的正式证件（Client ID + Client Secret），悄悄跑到“欢乐世界”后台的“令牌办公室”（AS的 /token 端点）。
8. 令牌办公室核发“游玩门票”和“身份卡” (颁发令牌 - AS工作)：
   • 令牌办公室（AS）工作人员：
     • 仔细检查“兑换券”（授权码）真假。
     • 核对“畅游助手”的证件（Client ID/Secret）并确认无误。
     • 向身份管理处（IdP）查询： “用户123456同意给‘畅游助手’哪些权限？他的公开信息（比如名字、头像）可以给吗？” (AS 基于IdP的身份信息生成ID Token和UserInfo)
   • 确认无误后，工作人员制作并发放：
     • “游玩门票” (访问令牌 Access Token)： 这张票上印着“允许用户123456通过‘畅游助手’App预订和乘坐‘极速飞龙’一次”（包含权限范围 scope）。
     • 可选 “续票凭证” (刷新令牌 Refresh Token)： 如果“游玩门票”过期了（比如当天有效），App可以凭这个凭证再来换新票，不用你再跑一趟售票处重新认证授权。
     • “身份卡” (ID Token - 来自IdP)： 一张小卡片，上面写着官方认证的信息：“持票人：用户123456（你的唯一标识），由欢乐世界于X时X分签发”。这证明了你成功认证过身份。
   • 把这些票和卡都给了“畅游助手”App的后台。
9. App用“游玩门票”帮你订项目 (访问资源)： “畅游助手”App拿到“游玩门票”（Access Token），带着它去“极速飞龙”项目的后台系统（资源服务器RS），说：“这是用户123456的票，帮他预订下午3点场次。” App在请求中出示这张“门票”。
10. “极速飞龙”项目组验票 (资源服务器验证令牌)： “极速飞龙”项目组（资源服务器）的工作人员：
    • 拿出一个“欢乐世界”官方发的验票机（对应RS配置的令牌验证密钥或自省端点）。
    • 扫描“游玩门票”（验证Access Token的签名、有效期）。
    • 查看票面信息：确实是官方发的真票！有效期没过！并且票上明确写着允许预订“极速飞龙”（检查scope）。
    • 于是，项目组确认预订成功，并把信息返回给App。App再告诉你预订成功！
11. 后续可能：
    • 如果“游玩门票”过期了（比如一天有效），App可以用“续票凭证”（Refresh Token）再去“令牌办公室”（/token端点）换一张新的“游玩门票”（新的Access Token），无需你再次去闸机验票和售票处同意。
    • 如果App想显示你的名字和头像，它可以用“游玩门票”（Access Token）去“欢乐世界”的“游客信息服务中心”（/userinfo端点，由IdP提供或AS代理）查询，服务中心确认票有效后，返回你的公开信息（姓名、头像）。

功能切分总结 (回到关键点)：

• 身份提供者 (IdP) - “入园闸机 & 身份信息库”：
  • 核心工作： 证明“你是谁” (用户认证) 和 管理你的核心身份档案。
  • 在流程中：负责第4步的“验票入园/刷脸”。
  • 提供生成ID Token所需的身份断言。
  • 提供/userinfo端点查询用户信息。
• 授权服务器 (AS) - “售票处 & 令牌办公室”：
  • 核心工作： 管理“谁(客户端)能代表你做什么”(授权) 和 发放“通行证”(令牌)。
  • 在流程中：负责检查App资质(第3步)、征得你的同意(第5步)、发放“兑换券”(第6步)、验证“兑换券”和App凭证(第8步)、制作并发放“游玩门票”(Access Token)、“续票凭证”(Refresh Token)、“身份卡”(ID Token) (第8步)。
  • 定义令牌规则，提供验证令牌的方法（如JWKS端点）。
• 协作关键点：
  • AS 依赖 IdP 来确认用户身份（第4步）。
  • AS 在征得用户同意（第5步）和确认客户端合法后，综合IdP的身份断言和用户的授权决策，颁发代表授权的Access Token 和 代表认证的ID Token。
  • 资源服务器（游乐项目）只认AS发的票（Access Token），不直接和IdP打交道。

一句话比喻：

IdP (闸机/档案库) 是确认“你是你”的保安。AS (售票处/令牌办) 是根据保安确认结果和你本人的同意，给第三方App开“游玩许可”的票务中心。游乐项目只认票务中心开的真票。

小记

1. 策略执行点/策略决策点 (PEP/PDP) - 高级架构概念
   • 在更细粒度的授权架构（如 ABAC）中：
     • 策略执行点 (PEP)： 通常集成在资源服务器中。在收到客户端的访问请求（携带Access Token）后，向 策略决策点 (PDP) 发起授权决策请求（“这个Token对这个资源执行这个操作允许吗？”）。
     • 策略决策点 (PDP)： 评估策略规则，做出“允许”或“拒绝”的决策，并将结果返回给 PEP。AS 有时会包含一个 PDP 组件，或者 PDP 是一个独立的服务（如 Open Policy Agent）。
   • 与 OAuth 2.1 的关系： OAuth 2.1 主要定义了如何获取访问令牌（代表粗粒度授权 Scope）。访问令牌本身通常包含足够的信息（Scope，可能还有 Claims）让 RS 做出基本的访问控制决策（RS 这时充当了简单的 PEP+PDP）。对于更复杂的授权（基于用户属性、资源属性、环境属性等），往往会将 OAuth 2.1 与更精细的授权系统结合使用。
   • 为什么不算核心 OAuth 2.1 “实体”？ 它们是授权模型扩展的一部分，超出了 OAuth 2.1 核心协议规范的范围。