基于浏览器的应用的 OAuth 2.0

6.1.2.1. 会话和 OAuth 端点

BFF 提供一组端点，它们对于 实现基于浏览器的应用与 BFF 之间的交互至关重要。 本节稍微更详细地讨论这些端点，以阐明其 目的和用例。¶

“检查会话”端点（上图中的步骤 B 和 I） 是由基于浏览器的应用调用的 API 端点。请求 会在可用时携带会话信息，使 BFF 能够检查是否存在 活动会话。响应应向基于浏览器的应用表明 会话是否处于活动状态。此外，BFF 可以包含其他 信息，例如已认证用户的身份信息。¶

启动授权码流程的端点 （步骤 C）由浏览器通过导航联系。当应用 在检查会话（步骤 B）后检测到未认证状态时，它可以 将浏览器导航到此端点。这样做允许 BFF 使用 重定向进行响应，将浏览器带到授权服务器。用于 启动此流程的端点通常由支持在 Web 服务器上运行的机密客户端的 OAuth 2.0 库作为“login”端点提供。请注意， BFF 也可以在步骤 B 中检测到没有活动会话时启动授权码流程。 在这种情况下，BFF 会在响应中返回授权 URI，并期望应用 使用该 URI 触发导航事件。然而，此场景需要 自定义实现，并且更难使用标准 OAuth 库。¶

接收授权码的端点（步骤 E） 由浏览器内部的导航事件调用。此时， 应用未加载，且无法处理重定向。与 流程启动类似，处理重定向的端点由 标准 OAuth 库提供。BFF 可以用一个 触发浏览器加载应用的重定向来响应该请求。¶

最后，BFF 还可以向 应用提供一个“logout”端点，该端点未在上图中描绘。 logout 端点的确切行为取决于应用需求。请注意，标准 OAuth 库通常也会提供“logout” 端点的实现。¶

6.1.2.2. 刷新令牌

使用刷新令牌时，如 [RFC9700] 的 第 4.14 节所述，BFF 获取刷新令牌 （步骤 F）并将其与用户的会话关联。¶

如果 BFF 注意到用户的访问令牌已经 过期，并且 BFF 拥有刷新令牌，它可以使用该刷新令牌来获取 新的访问令牌。由于 BFF OAuth 客户端是机密客户端，它 会在刷新令牌请求中使用客户端认证。通常，BFF 在处理来自前端的 API 调用时内联执行这些步骤。在这种 情况下，这些未在图中明确显示的步骤会发生 在步骤 J 和 K 之间。将所有令牌信息保留在 服务器端可用的 BFF，也可以在观察到令牌 过期事件时请求新的访问令牌，以提升 API 请求性能。¶

当刷新令牌过期时，如果不运行一个全新的授权码流程， 就无法获得有效访问令牌。 因此，将 BFF 管理的基于 Cookie 的会话的生命周期 配置为等于刷新令牌的最长生命周期是合理的。 此外，当 BFF 得知某个活动会话的刷新令牌 不再有效时，使该会话失效也是合理的。¶

6.1.2.3. 基于 Cookie 的会话状态

BFF 依赖浏览器 Cookie（[I-D.ietf-httpbis-rfc6265bis]）来跟踪 用户的会话，该会话用于访问用户的令牌。基于 Cookie 的 会话，无论是服务器端还是客户端，都有一些缺点。¶

服务器端会话只暴露一个会话标识符，并 将所有数据保留在服务器上。这样做可以确保对 活动会话具有很高程度的控制，并且可以随时撤销任何会话。 此方法的缺点是对可扩展性的影响，需要诸如 “sticky sessions”或“session replication”之类的解决方案。鉴于这些缺点，只有在小规模场景中才推荐 将服务器端会话与 BFF 一起使用。¶

客户端会话将所有数据以 签名且可选加密的对象推送到浏览器。此模式使服务器不必 跟踪任何会话数据，但会严重限制对活动 会话的控制，并使处理会话撤销变得困难。然而，当 客户端会话在 BFF 的上下文中使用时，这些属性会 显著改变。由于基于 Cookie 的会话仅用于获取用户的 令牌，所有控制和撤销属性都源自访问 令牌和刷新令牌的使用。撤销用户的访问令牌和/或 刷新令牌就足以阻止对受保护资源的持续访问，而无需 显式使基于 Cookie 的会话失效。¶

保护会话 Cookie 的最佳实践在 第 6.1.3.2 节中讨论。¶

6.1.2.4. 组合 OAuth 和 OpenID Connect

此应用架构使用的 OAuth 流程可以 通过在授权请求（C）中包含必要的 OpenID Connect 作用域 与 OpenID Connect 结合（至少包含 [OpenID] 第 3.1.2.1 节定义的 openid 作用域）。 在这种情况下，BFF 会在步骤 F 中 接收 ID Token。BFF 可以将 ID Token 中的信息与用户的会话关联， 并在步骤 B 或 I 中将其提供给应用。¶

需要时，BFF 可以使用与用户会话关联的访问令牌 向 UserInfo 端点发出请求。¶

6.1.2.5. 实际部署策略

提供静态 JavaScript 代码与处理 OAuth 令牌和转发请求 是两项不同的职责。在上面给出的图中，BFF 和静态 Web 主机 显示为两个独立实体。在现实世界部署中，这些组件可以部署为 单个服务（即 BFF 提供静态 JS 代码）、两个独立 服务（即 CDN 和 BFF），或单个服务中的两个组件 （即云平台上的静态托管和无服务器函数）。¶

请注意，可以进一步定制此 架构以适配特定场景。例如，依赖内部和外部资源服务器的应用 可以选择将内部资源服务器与 BFF 一起托管。 在这种场景中，到内部资源服务器的请求直接在 BFF 处理， 无需通过网络转发请求。从 资源服务器的视角来看，授权不会改变，因为用户会话在内部会转换为 访问令牌及其声明。¶

6.1.3.1. 授权码授权

使用 BFF 的主要好处是 BFF 能够 充当机密客户端。因此，BFF MUST 通过与授权服务器建立凭据来充当机密 客户端。此外， BFF MUST 使用 [RFC9700] 的 第 2.1.1 节中所述的 OAuth 2.0 授权码授权来发起 访问令牌请求。¶

6.1.3.2. Cookie 安全

BFF 使用 Cookie 创建用户会话，该会话 通过服务器端或客户端会话状态直接与用户的令牌关联。 鉴于这些 Cookie 的敏感性质，它们 必须得到适当保护。¶

以下 Cookie 安全指南与 此特定 BFF 架构相关：¶

• BFF MUST 为其 Cookie 启用 Secure 标志¶

• BFF MUST 为其 Cookie 启用 HttpOnly 标志¶

• BFF SHOULD 为其 Cookie 启用 SameSite=Strict 标志¶

• BFF SHOULD 将其 Cookie 路径设置为 /¶

• BFF SHOULD NOT 为 Cookie 设置 Domain 属性¶

• BFF SHOULD 使用 __Host 前缀 作为其 Cookie 名称的开头（[I-D.ietf-httpbis-rfc6265bis]）¶

注意：在新的部署中，上述所有要求 很可能都易于实现。“SHOULD”项目之所以不是 “MUSTs”，只是为了让现有架构也能合规。这些要求的 影响列在下文。¶

这些 Cookie 安全指南与 HTTPS 的使用相结合，有助于抵御直接针对基于 Cookie 的会话的攻击。 由于 Secure 和 HttpOnly Cookie 标志，会话 劫持不可行。__Host 前缀会阻止 Cookie 与子域共享，从而抵御基于子域的 会话劫持或会话固定攻击。在典型的 BFF 部署 场景中，没有理由使用比上述要求更宽松的 Cookie 安全设置。 偏离这些设置需要针对当前部署场景给出适当的 理由。¶

此外，当使用包含 访问令牌的客户端会话时（相对于令牌只存在于 服务器上的服务器端会话），BFF SHOULD 加密其 Cookie 内容。 虽然使用 Cookie 加密不会影响 BFF 模式的安全属性，但它确实 能确保存储在 Cookie 中的令牌绝不会以明文格式写入用户的本地 持久存储。这项安全措施有助于在攻击者能够从 硬盘读取 Cookie 的情况下确保令牌的机密性。此类攻击可以通过在 受害者计算机上运行的恶意软件发起。请注意，虽然加密 Cookie 内容可以防止 直接访问嵌入的令牌，但它仍允许攻击者在会话劫持攻击中使用 加密 Cookie。¶

有关 Cookie 安全最佳实践的更多指导，我们 参考 OWASP Cheat Sheet 系列（[OWASPCheatSheet]）。¶

6.1.3.3. 跨站请求伪造保护

基于浏览器的应用与 BFF 之间的交互依赖 Cookie 进行认证和授权。与其他 基于 Cookie 的交互类似，BFF 必须考虑跨站请求 伪造（CSRF）攻击。成功的 CSRF 攻击可能允许攻击者发往 BFF 的请求触发对受保护资源的传出调用。¶

BFF MUST 实现适当的 CSRF 防御。确切的 机制或机制组合取决于 BFF 部署所在的确切域， 如下文所讨论。¶

6.1.3.4. BFF 架构中的隐私注意事项

BFF 模式要求基于浏览器的 应用通过后端 BFF 组件将所有请求转发到资源服务器。 因此，BFF 组件能够观察应用和资源服务器之间的所有请求 和响应，这可能产生相当大的隐私影响。¶

当基于浏览器的应用和 BFF 由同一方构建和 部署时，隐私影响可能很小。然而，当 此模式使用由第三方提供或托管的 BFF 组件实现时， 就需要考虑这种隐私影响。¶

6.1.3.5. 运维注意事项

由于 BFF 会代表前端将所有请求转发到资源 服务器，因此应注意确保资源 服务器了解此组件，并为速率 限制和其他反滥用措施使用适当策略。例如，如果 BFF 作为 单实例服务部署，而资源服务器根据 IP 地址限制请求速率， 它可能会开始阻止请求，因为许多用户的浏览器看起来都来自 BFF 的单个 IP 地址。¶

6.1.3.6. 代理 限制

BFF 通过接受来自 前端的请求并将其转发到资源服务器来充当代理服务。入站请求 携带 Cookie，BFF 会在出站 请求中将其转换为访问令牌。（请注意，这使它更像应用层反向代理， 而不是 HTTP 代理。）除了 CSRF 攻击外，攻击者还可能尝试 操纵 BFF，使其将请求转发到非预期主机。如果攻击者 成功利用这一点，他们可能会将 BFF 重定向到任意服务器， 从而可能暴露用户的访问令牌。¶

为缓解此风险，BFF MUST 通过在转发 请求前验证目标主机来强制执行严格的 出站请求控制。这需要维护一个经批准资源 服务器的显式允许列表，确保请求只被代理到预定义后端（例如， /bff/orders/create 专门映射到 https://order-api.example.com/create）。如果需要基于 路径的动态路由（例如 /bff/orders/{id}），BFF MUST 进行 严格验证，以确保只有授权目标可访问。 此外，按端点限制允许的 HTTP 方法可以 进一步减少攻击向量。¶

实现动态可配置代理时， BFF MUST 确保它只允许请求显式许可的主机和 路径。未能强制执行这些限制可能导致未授权访问和 访问令牌泄漏。¶

6.1.3.7. 高级 安全

在 BFF 模式中，所有 OAuth 职责都已 移交给 BFF，即充当机密客户端的服务器端组件。由于 服务器端应用在比基于浏览器的 应用更受控的环境中运行，因此采用高级 OAuth 安全实践会更容易。 示例包括基于密钥的客户端认证和发送者约束 令牌。¶

6.1.4.1. 攻击 场景和后果

如果攻击者能够在应用的执行上下文中执行恶意代码 （例如 JavaScript 或 WASM），以下 攻击场景就会变得相关：¶

• 通过用户的浏览器代理请求（第 5.1.4 节）¶

请注意，此攻击场景会导致以下 后果：¶

• 客户端劫持（第 5.2.3 节）¶

请注意，客户端劫持是一个 由基于浏览器的应用本质决定的攻击场景。因此，除了首先阻止恶意 代码执行之外，没有任何东西能够防止此类攻击。可以帮助实现这一点的技术包括 遵循安全编码指南、代码分析，以及部署深度防御 机制，例如内容安全策略（[W3C.CSP3]）。¶

在此架构中，BFF 是处理 各种安全特定职责和基于代理行为的关键组件。虽然 讨论基于代理应用的安全实现 超出了本文档范围，但必须注意，BFF 中的安全漏洞 可能对应用产生重大影响。¶

最后，BFF 处于一个独特位置，可以观察 基于浏览器的应用和资源服务器之间的所有流量。如果 高安全性应用希望实现异常检测或速率 限制，那么这样的 BFF 将是理想位置。此类限制可以 进一步帮助缓解客户端劫持的后果。¶

6.1.4.2. 已缓解的攻击场景

下列其他攻击场景由 BFF 应用架构有效 缓解：¶

• 单次执行令牌窃取（第 5.1.1 节）¶

• 持久性令牌窃取（第 5.1.2 节）¶

• 新令牌的获取和提取（第 5.1.3 节）¶

BFF 通过不向基于浏览器的应用 暴露任何令牌来抵御前两个攻击场景。即使攻击者 完全控制了应用，也根本没有可被 窃取的令牌。¶

第三个场景中，攻击者通过运行静默流程获得新的 访问令牌（以及可选的刷新令牌）， 通过使 BFF 成为机密客户端得到缓解。即使攻击者 成功获得授权码，也会因缺少客户端凭据而无法交换此 代码。此外，PKCE 的使用 可以防止针对授权码的其他攻击。¶

由于刷新令牌和访问令牌由 BFF 管理， 并且不暴露给浏览器，潜在攻击的以下两个后果 变得无关：¶

• 利用被盗刷新令牌（参见第 5.2.1 节）¶

• 利用被盗访问令牌（参见第 5.2.2 节）¶

6.1.4.3. 总结

BFF 的架构比仅浏览器应用复杂得多。 它需要部署和运行 服务器端 BFF 组件。此外，此模式要求应用与资源服务器之间的所有 交互都由 BFF 代理。根据部署模式，这种代理行为可能会给 服务器端组件增加显著负担。如果 BFF 充当资源 服务器，请参见第 6.2.2.6 节以获取额外说明。¶

然而，由于 BFF 架构 模式的性质，它提供了强安全保证。使用 BFF 还确保 应用的攻击面不会因使用 OAuth 而增加。唯一可行的 攻击模式是劫持用户浏览器中的客户端应用，这是 Web 应用固有的问题。¶

强烈建议业务 应用、敏感应用以及处理个人 数据的应用采用此架构。¶

6.2.2.1. 会话和 OAuth 端点

令牌中介后端的大多数端点实现 类似于 BFF 所描述的实现。¶

• “检查会话”端点（上图中的步骤 B 和 I） 是由基于浏览器的 应用调用的 API 端点。请求会在可用时携带会话信息， 使后端能够检查是否存在活动会话。响应应 向基于浏览器的应用表明会话是否处于活动状态。 如果找到活动会话，后端会在 响应中包含访问令牌。此外，后端可以包含其他信息， 例如已认证用户的身份信息。¶

• 启动授权 码流程的端点（步骤 C）与 BFF 架构所描述的端点相同。更多细节参见第 6.1.2.1 节。¶

• 接收授权 码的端点（步骤 E）与 BFF 架构所描述的端点相同。更多细节参见第 6.1.2.1 节。¶

• 支持 logout 的端点与 BFF 架构所描述的端点相同。更多细节参见第 6.1.2.1 节。¶

6.2.2.2. 刷新 令牌

使用刷新令牌时，如 [RFC9700] 的 第 4.14 节所述，令牌中介后端 在步骤 F 中获取刷新令牌，并将其与用户的会话关联。¶

如果资源服务器拒绝访问令牌， 应用可以联系令牌中介后端来请求新的访问 令牌。令牌中介后端依赖与此 请求关联的 Cookie 来查找用户的刷新令牌，并使用 刷新令牌发出令牌请求。这些步骤未在图中显示。请注意，此刷新 令牌请求来自后端，即机密客户端，因此需要 客户端认证。¶

当刷新令牌过期时，如果不启动一个全新的授权码授权， 就无法获得有效访问令牌。 因此，如果事先知道此类信息，将基于 Cookie 的会话的生命周期 配置为等于刷新令牌的最长生命周期是合理的。 此外，当令牌中介后端得知某个 活动会话的刷新令牌不再有效时，使会话 失效是合理的。¶

6.2.2.3. 访问令牌 作用域

根据正在访问的资源服务器以及 授权服务器处的作用域配置，应用可能希望 请求具有不同作用域配置的访问令牌。这一行为 会允许应用遵循使用最小作用域 访问令牌的最佳实践。¶

应用可以在检查活动会话（步骤 A/I）时 将所需作用域告知令牌中介后端。由 令牌中介后端决定此前获得的访问令牌是否符合 所需的作用域条件。¶

需要注意，如果 不加区分地应用，令牌中介后端的这种访问令牌缓存 机制可能导致作用域提升风险。如果缓存的访问令牌具有前端请求作用域的超集， 令牌中介后端 SHOULD NOT 将其返回给前端；相反，它 SHOULD 使用刷新令牌从授权服务器请求一个具有较小作用域集合的 访问令牌。请注意，支持这种访问令牌下调作用域机制 由授权服务器自行决定。¶

在依赖 [RFC8707] 为特定资源服务器获取访问令牌时， 令牌中介后端可以使用与下调作用域类似的机制。¶

6.2.2.4. 基于 Cookie 的会话状态

与 BFF 类似，令牌中介后端依赖 浏览器 Cookie 来跟踪用户会话。适用于 BFF 的相同实现 指南和安全注意事项也适用，如第 6.1.2.3 节所讨论。¶

6.2.2.5. 组合 OAuth 和 OpenID Connect

与 BFF 类似，令牌中介后端可以选择 在单个流程中组合 OAuth 和 OpenID Connect。更多细节参见第 6.1.2.4 节。¶

6.2.2.6. 实际部署场景

提供静态 JavaScript 或 WASM 代码与处理和授权服务器的交互 是两项不同的职责。在上面给出的图中，令牌中介后端和静态 Web 主机 显示为两个独立实体。在现实世界部署场景中，这些 组件可以部署为单个服务（即令牌中介 后端提供静态代码）、两个独立服务（即 CDN 和 令牌中介后端），或单个服务中的两个组件（即云平台上的静态 托管和无服务器函数）。这些部署 差异不会影响此模式中描述的关系，但可能 影响其他实际事项，例如需要正确配置 CORS 以 启用跨源通信。¶

6.2.3.1. 授权码授权

使用令牌中介后端的主要好处是 后端能够充当机密客户端。因此， 令牌中介后端 MUST 充当机密客户端。此外， 令牌中介后端 MUST 使用 [RFC9700] 的 第 2.1.1 节中所述的 OAuth 2.0 授权码授权 来发起访问令牌请求。¶

6.2.3.2. Cookie 安全

令牌中介后端使用 Cookie 创建用户 会话，该会话通过服务器端或客户端会话状态直接与用户的令牌关联。 与 BFF 相同的 Cookie 安全指南适用，如第 6.1.3.2 节所讨论。¶

6.2.3.3. 跨站请求伪造保护

基于浏览器的应用与 令牌中介后端之间的交互依赖 Cookie 进行认证和 授权。与 BFF 一样，令牌中介后端必须 考虑跨站请求伪造（CSRF）攻击。¶

第 6.1.3.3 节概述了 针对 CSRF 攻击的各种缓解策略的细微差异。特别是对于 令牌中介后端，这些 CSRF 防御只适用于 应用可获取其访问令牌的一个或多个端点。¶

6.2.3.4. 高级 OAuth 安全

令牌中介后端是作为服务器端组件运行的机密客户端。 令牌中介后端可以采用 机密客户端的安全最佳实践，例如基于密钥的客户端 认证。¶

6.2.4.1. 攻击场景和后果

如果攻击者能够在应用的执行上下文中执行恶意代码， 以下攻击场景就会变得 相关：¶

• 访问令牌的单次执行令牌窃取（第 5.1.1 节）¶

• 访问令牌的持久性令牌窃取（第 5.1.2 节）¶

• 通过用户的浏览器代理请求（第 5.1.4 节）¶

请注意，这些攻击场景会导致以下 后果：¶

• 利用被盗访问令牌（第 5.2.2 节）¶

• 客户端劫持（第 5.2.3 节）¶

将访问令牌暴露给基于浏览器的应用 是令牌中介后端架构模式背后的核心思想。 因此，访问令牌会受到恶意 基于浏览器代码的令牌窃取威胁。¶

6.2.4.2. 已缓解的攻击场景

下列其他攻击场景由令牌中介后端有效 缓解：¶

• 刷新令牌的单次执行令牌窃取（第 5.1.1 节）¶

• 刷新令牌的持久性令牌窃取（第 5.1.2 节）¶

• 新令牌的获取和提取（第 5.1.3 节）¶

令牌中介后端通过不向基于浏览器的应用 暴露刷新令牌来抵御前两个攻击 场景。即使攻击者完全控制了应用，也根本 没有可被窃取的刷新令牌。¶

第三个场景中，攻击者通过运行静默流程获得新的 访问令牌（以及可选的刷新令牌）， 通过使令牌中介后端成为机密客户端得到缓解。即使 攻击者成功获得授权码，也会因缺少客户端凭据而无法 交换此代码。此外，使用 PKCE 可防止 针对授权码的其他攻击。¶

由于令牌中介后端的性质， 潜在攻击的以下后果变得无关：¶

• 利用被盗刷新令牌（参见第 5.2.1 节）¶

6.2.4.3. 额外 防御

虽然此架构会固有地暴露访问令牌， 但仍有一些额外防御可以帮助提升应用的安全态势。¶

6.2.4.4. 总结

令牌中介后端的架构比仅浏览器应用 更复杂，但不如运行代理型 BFF 复杂。 与复杂性类似，令牌中介后端提供的 安全属性介于使用 BFF 和运行 仅浏览器应用之间。¶

令牌中介后端解决了通常会 授予攻击者代表用户长期访问权限的典型场景。然而，由于 访问令牌窃取的后果，攻击者仍然能够获得 对资源服务器的直接访问。¶

在考虑令牌中介后端架构时， 强烈建议评估采用第 6.1 节所讨论的完整 BFF 是否可行。 只有在用例或系统需求会阻止 使用代理型 BFF 时，才应考虑使用令牌中介后端而不是 完整 BFF。¶

6.3.2.1. 授权码授权

作为公共客户端的基于浏览器的应用 MUST 在获取访问令牌时实现 Proof Key for Code Exchange （PKCE [RFC7636]）扩展， 并且授权服务器 MUST 支持并 对此类客户端强制执行 PKCE。¶

PKCE 扩展可以防止一种攻击：授权码被截获 并由恶意客户端交换为访问令牌。它通过向 授权服务器提供一种方式，以验证交换 授权码的客户端实例与启动该流程的客户端实例是同一个。¶

6.3.2.2. 跨站请求伪造保护

基于浏览器的应用 MUST 防止针对其重定向 URI 的 CSRF 攻击。 这可以通过以下任一方式完成：¶

• 配置授权服务器， 要求此客户端使用 PKCE¶

• 使用并验证 OAuth state 参数的唯一值来携带 CSRF 令牌¶

• 如果应用也使用 OpenID Connect，则按照 [OpenID] 中的描述，使用并验证 OpenID Connect 的 nonce 参数¶

有关为授权码流程选择适当 CSRF 防御的其他细节， 请参见 [RFC9700] 的 第 2.1 节。¶

6.3.2.3. 刷新 令牌

对于基于浏览器的客户端，刷新令牌通常 是持有者令牌，除非应用显式使用 DPoP [RFC9449]。因此， 刷新令牌泄漏的风险 大于访问令牌泄漏，因为攻击者可能能够 继续使用被盗刷新令牌来获取新的访问令牌，并且可能 不会被 授权服务器检测到。¶

授权服务器可以选择是否向基于浏览器的 应用签发刷新令牌。然而，鉴于第三方 Cookie 阻止 机制的影响，使用刷新令牌已经变得明显更有吸引力。 [RFC9700] 在 [RFC6749] 的建议基础上，描述了围绕刷新令牌的一些 额外要求。符合此 BCP 的应用和授权 服务器如果向基于浏览器的 应用签发刷新令牌，也 MUST 遵循 [RFC9700] 中围绕刷新令牌的建议。¶

特别是，授权服务器：¶

• MUST 要么在每次使用时轮换刷新令牌， 要么使用 [RFC9700] 的 第 4.14.2 节所述的发送者约束刷新令牌¶

• MUST 要么为刷新令牌设置最长生命周期， 要么在刷新令牌在某段时间内未被使用时使其过期¶

• 在签发轮换后的刷新令牌时，如果刷新令牌具有预先设定的 过期时间，MUST NOT 将新的刷新令牌生命周期延长到 初始刷新令牌生命周期之外¶

将总体刷新令牌生命周期限制为 初始刷新令牌的生命周期，可以确保被盗刷新令牌不能 被无限期使用。¶

例如：¶

• 用户授权某个应用，签发一个 持续 10 分钟的访问令牌，以及一个持续 8 小时的刷新令牌¶

• 10 分钟后，初始访问令牌 过期，因此应用使用刷新令牌获取新的访问 令牌¶

• 授权服务器返回一个新的访问 令牌，持续 10 分钟，以及一个新的刷新令牌，持续 7 小时 50 分钟¶

• 这会持续进行，直到距离 初始授权过去 8 小时¶

• 此时，当应用尝试 在 8 小时后使用刷新令牌时，请求会失败， 应用必须重新发起一个依赖用户认证或此前已建立会话的授权码流程¶

授权服务器 SHOULD 将 刷新令牌的生命周期与用户在授权服务器上的已认证会话关联起来。 这样可确保当用户登出时，先前向 基于浏览器的应用签发的刷新令牌变为无效，从而模拟单点登出场景。 授权服务器 MAY 相比其他公共 客户端，为基于浏览器的应用设置不同的刷新令牌签发、 生命周期和过期策略。¶

6.3.3.1. 客户端 认证

由于基于浏览器的应用源代码会 交付到最终用户的 浏览器，因此不适合包含预置密钥。因此， 基于浏览器的应用通常按 [RFC6749] 的 第 2.1 节定义部署为公共客户端。¶

静态包含在分发给 多个用户的应用中的密钥，不应被视为机密密钥，因为某个 用户可能检查自己的副本并得知共享密钥。基于这一 原因，以及 [RFC6819] 的 第 5.3.1 节所述原因，授权 服务器 MUST NOT 要求使用共享密钥的基于浏览器 应用进行客户端认证，因为这除了 客户端标识外没有任何价值，而客户端标识已经由 client_id 参数提供。¶

仍然要求 SPA 客户端使用静态 包含的共享 密钥的授权服务器，MUST 将该客户端视为公共 客户端，并且不得接受该密钥作为客户端身份的证明。在没有 额外措施的情况下，这类客户端会受到客户端冒充的影响 （见下文第 6.3.3.2 节）。¶

6.3.3.2. 客户端 冒充

如 [RFC6749] 的 第 10.2 节所述，授权 服务器 SHOULD NOT 在没有用户同意或交互的情况下自动处理授权请求， 除非授权 服务器能够确认客户端应用的身份。¶

如果授权服务器将重定向 URI 限制为一组固定的绝对 HTTPS URI，防止使用通配符域、通配符路径或通配符 查询字符串组件， 则授权服务器 MAY 接受这种已注册绝对 HTTPS URI 的精确匹配， 作为客户端身份的 证明，用于决定在 client_id 的先前请求已经被批准时，是否自动 处理授权请求。¶

6.3.3.3. 浏览器内通信流程的安全性

在基于浏览器的应用中，常见做法是在次级窗口（例如 popup 或 iframe） 中执行 OAuth 流程，而不是重定向主窗口。 在这些流程中，基于浏览器的应用保持对主窗口的控制，例如 为了避免页面刷新，或静默运行基于 frame 的流程。¶

如果基于浏览器的应用和授权服务器 在不同 frame 中调用，它们必须使用浏览器内通信 技术，例如 postMessage API（又称 [WebMessaging]），而不是顶层 重定向。 为保证消息的机密性和真实性，postMessage 的发起方 源和接收方源都 MUST 使用 postMessage API 固有提供的机制进行验证（[WebMessaging] 中的第 9.3.2 节）。¶

[RFC9700] 的 第 4.18 节提供了有关 浏览器内通信流程安全性的额外细节，以及 基于浏览器的应用和授权服务器 MUST 采用以防御 这些攻击的对策。¶

6.3.3.4. 跨源 请求

在此场景中，应用使用浏览器 API 向授权服务器和资源服务器发送请求。鉴于 OAuth 2.0 的性质，这些请求通常是跨源的，受到浏览器强制执行的 跨源通信限制。 授权服务器和资源服务器 MUST 发送必要的 CORS 标头 （定义见 [Fetch]），以 允许应用发出必要的跨源请求。请注意，在 基于浏览器的 OAuth 客户端与授权服务器或资源服务器运行在同一 源的特殊场景中，不需要 CORS 策略即可启用必要的交互。¶

对于授权服务器，CORS 配置与 令牌端点相关，基于浏览器的应用在该端点用 授权码交换令牌。此外，如果授权服务器 向应用提供额外端点，例如 discovery metadata URLs、JSON Web Key Sets、dynamic client registration、revocation、introspection 或 user info 端点，这些端点也可能由 基于浏览器的应用访问。因此，授权服务器负责 在这些端点上支持 CORS。¶

本规范不包含 决定具体 CORS 策略实现的指南，该实现可以是 通配符源或更严格的配置。请注意，CORS 有两种 操作模式，具有不同的安全属性。第一种模式适用于 CORS 安全列表请求，以前称为简单请求，在这种模式中，浏览器 发送请求，并使用 CORS 响应标头来决定响应 是否可以暴露给客户端执行上下文。对于非 CORS 安全列表 请求，例如带有自定义请求标头的请求，浏览器会先 使用预检检查 CORS 策略。只有当服务器在预检响应中给出批准时， 浏览器才会发送实际 请求。¶

请注意，由于授权服务器的具体 配置，预检的 CORS 响应可能不同于实际请求的 CORS 响应。 在预检期间， 授权服务器只能验证提供的源，但在实际 请求期间，授权服务器拥有完整请求数据，例如客户端 ID。因此，授权服务器可以在 预检期间批准已知源，但在将该源与此特定客户端的预注册源列表比较后 拒绝实际请求。¶

6.3.4.1. 攻击场景和后果

如果攻击者能够在应用的执行上下文中执行恶意代码， 以下攻击场景就会变得 相关：¶

• 单次执行令牌窃取（第 5.1.1 节）¶

• 持久性令牌窃取（第 5.1.2 节）¶

• 新令牌的获取和提取（第 5.1.3 节）¶

• 通过用户的浏览器代理请求（第 5.1.4 节）¶

最危险的攻击场景是获取和 提取新令牌。在此攻击场景中，攻击者只与 授权服务器交互，这使客户端中 OAuth 功能的实际实现细节 变得无关。即使合法客户端 应用找到一种能够将令牌与攻击者完全隔离的方法，攻击者 仍然能够从授权服务器获取令牌。¶

请注意，这些攻击场景会导致以下 后果：¶

• 利用被盗刷新令牌（参见第 5.2.1 节）¶

• 利用被盗访问令牌（参见第 5.2.2 节）¶

• 客户端劫持（参见第 5.2.3 节）¶

6.3.4.2. 额外 防御

虽然此架构固有地容易受到 恶意基于浏览器代码的影响，但仍有一些额外防御可以帮助 提升应用的安全态势。请注意，这些 防御都不能处理或修复允许攻击者运行新 流程来获取令牌的根本问题。¶

6.3.4.3. 总结

总而言之，基于浏览器的 OAuth 客户端应用的架构很直接，但会显著增加 应用的攻击面。攻击者不仅能够劫持 客户端，还能从基于浏览器的应用中提取一整套功能完整的令牌。¶

不建议业务 应用、敏感应用以及处理个人 数据的应用使用此架构。¶

7.2.3.1. 重定向 URI 的操纵

如果攻击者能够使授权响应 被发送到其控制下的 URI，他们就会直接获得对授权响应的访问， 包括访问令牌。 [RFC9700] 中详细描述了执行此攻击的几种方法。¶

7.2.3.2. 浏览器历史记录中的访问 令牌泄漏

攻击者可以从 浏览器历史记录中获取访问令牌。 [RFC6819] 推荐的对策仅限于对令牌使用较短的 过期 时间，并指示浏览器不应缓存响应。 这些都不能完全防止此攻击，它们只能减少潜在 损害。¶

此外，许多浏览器现在还会将浏览器历史记录同步 到云服务和 多个设备，从而提供更广泛的攻击面，以便从 URL 中提取访问 令牌。¶

这在 [RFC9700] 的 第 4.3.2 节中有更详细的讨论。¶

7.2.3.3. 脚本操纵

攻击者可以通过各种 方式修改页面或向浏览器注入脚本，包括浏览器的 HTTPS 连接被拦截时， 例如被企业网络拦截。 虽然针对 TLS 层的攻击通常超出 基础安全建议的防护范围，但对于基于浏览器的 应用，这类攻击 更容易执行。注入的脚本可以使攻击者访问 页面上的所有内容。¶

当应用使用一种已知的标准方式获取访问令牌时， 页面上运行恶意脚本的风险可能会被 放大，也就是说攻击者 始终可以查看 window.location 变量来查找访问 令牌。这种威胁画像 不同于攻击者通过知道经授权码流程获得的访问令牌可能 存储在何处或如何存储，从而专门针对单个应用发起攻击。¶

7.2.3.4. 访问 令牌泄漏给第三方脚本

在基于浏览器的应用中使用第三方脚本相当常见，例如 分析工具、崩溃报告，甚至诸如社交媒体“like” 按钮之类的东西。 在这些情况下，应用作者可能无法完全 了解应用中运行的全部代码。当访问令牌在 片段中返回时，页面上的任何第三方脚本都可以看到它。¶

7.4.1.1. 攻击 Service Worker

使用 Service Worker 看似有前景的安全收益 值得更详细地讨论其安全限制。 为了针对相关攻击场景（第 5.1 节）充分保护应用， Service Worker 需要满足两个安全要求：¶

1. 防止攻击者外泄令牌¶

2. 防止攻击者获取一组新的 令牌¶

一旦注册，Service Worker 就会运行授权 码流程并获取令牌。由于 Service Worker 在自己的隔离执行环境中跟踪令牌， 它们无法被任何 应用代码触及，包括潜在的恶意代码。因此， Service Worker 满足了防止令牌外泄的第一项要求。 这实际上中和了第 5.1 节中讨论的前两个攻击场景。¶

为了满足第二项安全要求，Service Worker 必须能够保证控制合法 应用的攻击者不能执行新的授权码授权，这是 第 5.1.3 节中讨论的攻击。 由于 Service Worker 的性质，已注册的 Service Worker 能够 阻止所有发起此类新流程的传出请求，即使这些请求 发生在 frame 或新窗口中。¶

然而，在应用内部运行的恶意代码 可以注销此 Service Worker。注销 Service Worker 可能会对应用产生 显著功能影响，因此浏览器不会轻率处理此操作。 因此，被注销的 Service Worker 会被标记为 这种状态，但所有当前运行的实例仍保持活动，直到其 对应的浏览上下文被终止（例如通过关闭标签页或 窗口）。所以即使攻击者注销了 Service Worker，它仍然保持 活动，并能够防止攻击者到达授权 服务器。¶

注销 Service Worker 的一个后果是， 当打开新的浏览上下文时，它将不存在。因此，当 攻击者先注销 Service Worker，然后在 frame 中启动新流程时，frame 的浏览上下文将没有关联的 Service Worker。 因此，攻击者将能够运行自己的新 授权码授权，从 frame 的 URL 中提取授权码， 并将其交换为令牌。本质上，Service Worker 未能满足 第二项安全要求，使其容易受到攻击者获取一组新令牌的场景影响 （第 5.1.3 节）。¶

由于这些缺陷，再加上注册和维护 Service Worker 的显著 复杂性，不推荐此模式。¶

最后，请注意，单独使用 Service Worker 不会增加应用的攻击面。实践中，Service Worker 常被用于为旧版应用改造支持，以便在传出请求中包含 OAuth 访问令牌。 在这些场景中，Service Worker 不会改变应用的安全属性，而只是 简化应用的开发和维护。¶