6.1.2.1. 会话和 OAuth 端点

BFF 提供一组对于 实现基于浏览器的应用程序与 BFF 之间的交互至关重要的端点。 本节将更详细地讨论这些端点，以阐明其用途 和使用场景。¶

"检查会话" 端点（图 1中的 (B) 和 (I)）是由 基于浏览器的应用程序调用的 API 端点。会话信息可用时，请求会携带 该信息，使 BFF 能够检查活动 会话。响应应该向基于浏览器的应用程序表明 会话是否处于活动状态。此外，BFF 还可以包含其他信息，例如 已验证身份的用户的身份信息。¶

启动授权码流程的端点 (C) 由浏览器通过导航进行访问。当应用程序 在检查会话 (B) 后检测到未验证身份的状态时，可以将 浏览器导航至此端点。这样，BFF 就可以使用 重定向作出响应，将浏览器带到授权服务器。支持 在 Web 服务器上运行的机密客户端使用 OAuth 2.0 的库，通常会将启动此流程的 端点作为 "登录" 端点提供。请注意， BFF 也可以在检测到不存在活动会话时， 通过 (B) 启动授权码流程。在这种情况下，BFF 会在响应中返回授权 URI，并要求应用程序 使用此 URI 触发导航事件。然而，此场景需要 自定义实现，并使标准 OAuth 库更难使用。¶

接收授权码的端点 (E) 由浏览器内的导航事件调用。此时， 应用程序尚未加载，无法处理重定向。与 启动流程类似，处理重定向的端点由 标准 OAuth 库提供。BFF 可以使用重定向响应此请求， 从而触发浏览器加载应用程序。¶

最后，BFF 还可以向 应用程序提供 "注销" 端点，此端点未在图 1中描绘。注销 端点的确切行为取决于应用程序要求。请注意，标准 OAuth 库通常也会提供 "注销" 端点的实现。¶

6.1.2.2. 刷新令牌

按照 第 4.14 节，见 [RFC9700]中的说明使用刷新令牌时，BFF 会获取刷新令牌 (F) 并将其与用户的会话相关联。¶

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

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

6.1.2.3. 基于 Cookie 的会话状态

BFF 依赖浏览器 Cookie [RFC6265bis] 跟踪用户的 会话，该会话用于访问用户的令牌。服务端和客户端的 基于 Cookie 的会话都存在一些缺点。¶

服务端会话仅公开会话标识符，并将 所有数据保留在服务器上。这样做可以确保对 活动会话具有很高的控制程度，并且能够随时撤销任何会话。此 方法的缺点是会影响可扩展性，需要采用 "粘性会话" 或 "会话复制" 等解决方案。鉴于这些缺点，仅建议 在小规模场景中将服务端会话与 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 令牌。BFF 可以将 ID 令牌中的信息与用户的会话相关联，并在 (B) 或 (I) 中将其提供给应用程序。¶

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

6.1.2.5. 实用部署策略

提供静态 JavaScript 代码与处理 OAuth 令牌和转发请求是相互独立的 职责。在图 1中， BFF 和静态 Web 主机显示为两个独立实体。在实际 部署中，这些组件可以部署为单个服务（即，由 BFF 提供静态 JavaScript 代码）、两个独立服务（即，内容 分发网络 (CDN) 和 BFF），或者单个服务中的两个组件 （即，云平台上的静态托管和无服务器函数）。¶

请注意，可以进一步自定义此 架构以支持特定场景。例如，同时依赖 内部和外部资源服务器的应用程序可以选择将内部 资源服务器与 BFF 托管在一起。在该场景中，对内部 资源服务器的请求直接在 BFF 上处理，无需通过网络 转发请求。从资源 服务器的角度来看，授权并未发生变化，因为用户的会话会在内部转换为 访问令牌及其声明。¶

6.1.3.1. 授权码授权

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

6.1.3.2. Cookie 安全性

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

以下 Cookie 安全准则适用于 此特定 BFF 架构：¶

• BFF 必须为其 Cookie 启用 Secure 标志。¶

• BFF 必须为其 Cookie 启用 HttpOnly 标志。¶

• BFF 应该 为其 Cookie 启用 SameSite=Strict 标志。¶

• BFF 应该将 其 Cookie 路径设置为 /。¶

• BFF 不应该 为 Cookie 设置 Domain 属性。¶

• BFF 应该 以表明 Cookie 是通过 HTTP 设置的前缀 作为其 Cookie 名称的开头，例如使用 [COOKIES] 中定义的 __Host-Http- 前缀。¶

注意：在新部署中，上述所有要求 很可能都易于实现。"应该" 项未被视为 "必须" 项，以便现有架构能够 符合要求。这些要求的影响列于下文。¶

这些 Cookie 安全准则与 HTTPS 的使用相结合，有助于对抗直接以基于 Cookie 的会话为目标的攻击。由于使用了 Secure 和 HttpOnly Cookie 标志，会话劫持无法实现。__Host-Http- 前缀 可防止 Cookie 与子域共享，从而对抗 基于子域的会话劫持或会话固定攻击。在典型的 BFF 部署场景中，没有理由使用比上述要求更宽松的 Cookie 安全 设置。偏离这些设置时， 必须针对当前部署场景提供适当理由。¶

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

有关 Cookie 安全最佳实践的进一步指导， 请参阅 OWASP 速查表系列 [OWASPCheatSheet]。¶

6.1.3.3. 跨站请求伪造防护

基于浏览器的应用程序与 BFF 之间的交互依赖 Cookie 进行身份验证和授权。与其他 基于 Cookie 的交互类似，BFF 必须考虑跨站请求 伪造 (CSRF) 攻击。成功的 CSRF 攻击可能使攻击者 发送到 BFF 的请求触发对受保护资源的传出调用。¶

BFF 必须实现适当的 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 必须通过在转发请求前 验证目标主机，对传出请求实施严格控制。这要求 维护获批准资源服务器的明确允许列表，以确保 请求仅代理到预定义的后端（例如， /bff/orders/create 仅映射到 https://order-api.example.com/create）。如果需要基于 路径（例如 /bff/orders/{id}）进行动态路由，BFF 必须应用严格验证，以确保只能 访问获授权的目标。此外，按端点限制允许的 HTTP 方法可以进一步减少攻击向量。¶

实现可动态配置的代理时， BFF 必须确保其仅允许向 明确获准的主机和路径发出请求。未强制实施这些限制可能 导致未经授权的访问和访问令牌泄漏。¶

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 描述的端点类似。¶

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

• 启动授权 码流程的端点 (C) 与为 BFF 架构描述的端点相同。有关详细信息，请参阅第 6.1.2.1 节。¶

• 接收授权 码的端点 (E) 与为 BFF 架构描述的端点相同。有关详细信息，请参阅第 6.1.2.1 节。¶

• 支持注销的端点与 为 BFF 架构描述的端点相同。有关详细信息，请参阅第 6.1.2.1 节。¶

6.2.2.2. 刷新 令牌

按照 第 4.14 节，见 [RFC9700]中的说明使用刷新令牌时，令牌中介后端 会在 (F) 中获取刷新令牌，并将其与用户的会话相关联。¶

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

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

6.2.2.3. 访问令牌 范围

根据所访问的资源服务器以及 授权服务器上的范围配置，应用程序可能希望 请求具有不同范围配置的访问令牌。此行为将 使应用程序能够遵循使用最小范围 访问令牌的最佳实践。¶

应用程序可以在检查活动会话（(A) 和 (I)）时， 将所需范围告知令牌中介后端。由 令牌中介后端决定先前获取的访问令牌 是否符合所需的范围标准。¶

应该注意，如果不加区别地应用，令牌中介后端的 此访问令牌缓存机制可能造成范围提升风险。 如果缓存的访问令牌所具有的范围是 前端所请求范围的超集，令牌中介后端不应该将其返回给前端；相反，它应该使用刷新令牌向授权服务器请求 具有更小范围集合的访问令牌。请注意，是否支持 此类访问令牌范围缩减机制由 授权服务器决定。¶

依赖 [RFC8707] 中所述扩展为 特定资源服务器获取访问令牌时，令牌中介后端可以使用与 范围缩减机制类似的机制。¶

6.2.2.4. 基于 Cookie 的会话状态

与 BFF 类似，令牌中介后端依赖 浏览器 Cookie 跟踪用户的会话。基于 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 代码与处理 同授权服务器的交互是相互独立的职责。在图 2中， 令牌中介后端和静态 Web 主机显示为两个独立实体。 在实际部署场景中，这些组件可以部署为单个 服务（即，由令牌中介后端提供静态代码）、两个 独立服务（即，CDN 和令牌中介后端），或者单个服务中的两个 组件（即，云平台上的静态托管和无服务器函数）。 这些部署差异不会影响此模式中所述的关系， 但可能会影响其他实际事项，例如是否需要 正确配置 CORS 以启用跨源通信。¶

6.2.3.1. 授权码授权

使用令牌中介后端的主要好处是 后端能够充当机密客户端。因此， 令牌中介后端必须充当机密 客户端。此外，令牌中介后端必须 按照 第 2.1.1 节，见 [RFC9700]中的说明使用 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. 授权码授权

属于公共客户端的基于浏览器的应用程序在 获取访问令牌时必须实现 PKCE [RFC7636] 扩展，授权服务器也必须为此类客户端支持并强制使用 PKCE。¶

PKCE 扩展可防止授权码被截获并 由恶意客户端用来交换访问令牌的攻击，因为它为 授权服务器提供了一种方法，用于验证交换 授权码的客户端实例与启动流程的实例 是否相同。¶

6.3.2.2. 跨站请求伪造防护

基于浏览器的应用程序必须 防止针对其重定向 URI 的 CSRF 攻击。可以通过 以下任何一种方式实现：¶

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

• 为 OAuth state 参数使用并验证唯一值，以携带 CSRF 令牌¶

• 如果应用程序同时 使用 OpenID Connect，则按照 [OpenID]中的说明使用并验证 OpenID Connect nonce 参数¶

有关为授权码流程 选择适当 CSRF 防御措施的更多详细信息，请参阅 第 2.1 节，见 [RFC9700]。¶

6.3.2.3. 刷新 令牌

对于基于浏览器的客户端，除非应用程序明确 使用 DPoP [RFC9449]，否则刷新令牌通常是持有者令牌。因此， 刷新令牌泄漏所造成的风险 大于访问令牌泄漏，因为攻击者可能能够 继续使用被盗的刷新令牌获取新的访问令牌，并且可能 不会被 授权服务器发现。¶

授权服务器可以选择是否向基于浏览器的 应用程序签发刷新令牌。然而，鉴于第三方 Cookie 阻止 机制的影响，使用刷新令牌已经变得更具吸引力。 [RFC9700] 在 [RFC6749] 的建议基础上，说明了 与刷新令牌有关的一些其他要求。 如果向基于浏览器的应用程序签发刷新令牌，则符合此 BCP 的应用程序和授权 服务器必须同时遵循 [RFC9700] 中有关刷新令牌的建议。¶

具体而言，授权服务器：¶

• 必须在每次使用时轮换 刷新令牌，或者按照 第 4.14.2 节，见 [RFC9700]中的说明使用发送者约束刷新令牌¶

• 必须为 刷新令牌设置最长生命周期，或者在刷新令牌 一段时间内未被使用时使其过期¶

• 如果刷新令牌具有预先设定的过期时间，则在 签发轮换后的刷新令牌时不得将新刷新 令牌的生命周期延长至超过初始刷新令牌的生命周期¶

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

例如：¶

• 用户授权一个应用程序，签发 有效期为 10 分钟的访问令牌和有效期为 8 小时的刷新令牌。¶

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

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

• 此过程将持续到初始授权后的 8 小时结束。¶

• 此时，当应用程序在 8 小时后尝试 使用刷新令牌时，请求将失败，并且 应用程序必须重新启动依赖用户身份验证或先前已建立会话的 授权码流程。¶

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

6.3.3.1. 客户端 身份验证

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

作为分发给 多个用户的应用程序的一部分静态包含的秘密值不应被视为机密秘密值，因为任何 用户都可以检查自己的副本并获知共享秘密值。出于此 原因以及 第 5.3.1 节，见 [RFC6819]中所述的原因，授权 服务器不得要求使用共享秘密值对基于浏览器的 应用程序进行客户端身份验证，因为这除了 标识客户端外没有任何价值，而 client_id 参数已经提供了客户端标识。¶

仍要求 SPA 客户端使用静态包含的 共享秘密值的授权服务器必须将该客户端视为 公共客户端，并且不得接受此秘密值作为客户端身份的证明。如果不采取 其他措施，此类客户端将遭受客户端冒充 （参见第 6.3.3.2 节）。¶

6.3.3.2. 客户端 冒充

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

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

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

在基于浏览器的应用程序中，通常会在 弹出窗口或 iframe 等辅助窗口中执行 OAuth 流程，而不是 重定向主窗口。 在这些流程中，基于浏览器的应用程序会保持对主窗口的控制，例如 避免页面刷新或静默运行基于框架的流程。¶

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

第 4.17 节，见 [RFC9700]提供了有关 浏览器内通信流程安全性的更多详细信息，以及基于浏览器的应用程序和授权服务器为抵御这些攻击而必须采取的 对策。¶

6.3.3.4. 跨源 请求

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

对于授权服务器，CORS 配置与 令牌端点有关，基于浏览器的应用程序会在该端点 用授权码交换令牌。此外，如果授权服务器 向应用程序提供其他端点，例如发现元数据 URL、JSON Web 密钥集、动态客户端注册、撤销、内省 或用户信息端点，基于浏览器的应用程序也可能访问 这些端点。因此，授权服务器负责 在这些端点上支持 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 中提取访问 令牌。¶

第 4.3.2 节，见 [RFC9700]对此进行了更详细的讨论。¶

7.2.3.3. 操纵脚本

攻击者可以通过各种 方式修改页面或向浏览器中注入脚本，包括浏览器的 HTTPS 连接被 企业网络等 截获时。尽管针对 TLS 层的攻击通常不在 基本安全建议需要防范的范围 内，但对于基于浏览器的 应用程序而言，实施此类攻击要容易得多。注入的脚本可以使攻击者访问 页面上的所有内容。¶

当应用程序使用已知的标准方式获取访问令牌时， 页面上运行恶意脚本的风险可能会 增大；也就是说，攻击者始终可以查看 window.location 变量来寻找访问 令牌。此威胁特征 不同于攻击者通过了解由授权码流程获取的访问令牌可能 在何处或以何种方式 存储，从而专门针对某个应用程序的情况。¶

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

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

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 能够阻止所有启动此类新 流程的传出请求，即使这些请求发生在框架或新窗口中。¶

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

注销 Service Worker 的后果之一是， 打开新的浏览上下文时，它将不再存在。因此，当 攻击者先注销 Service Worker，随后在 框架中启动新流程时，该框架的浏览上下文将没有关联的 Service Worker。 因此，攻击者能够运行自己的新 授权码授权，从框架的 URL 中提取授权码， 并用其交换令牌。实质上，Service Worker 无法满足 第二项安全要求，因而容易遭受攻击者 获取一组新令牌的场景（第 5.1.3 节）。¶

由于这些缺点，再加上注册和维护 Service Worker 所带来的显著复杂性，因此不建议 使用此模式。¶

最后，请注意，使用 Service Worker 本身 不会扩大应用程序的攻击面。在实践中，Service Worker 通常用于改造旧式应用程序，使其支持 在传出请求中包含 OAuth 访问令牌。这些 场景中的 Service Worker 不会改变应用程序的安全属性，而只是 简化应用程序的开发和维护。¶