我已阅读完以下所有 RFC：
[2]: RFC 8252: 适用于原生应用的 OAuth 2.0（请注意，这不仅包括移动应用程序，还包括桌面应用程序。）
[3]建议基于浏览器的应用程序使用下列架构之一：
后端用于前端 (BFF)，其中后端代理与 OAuth 2.0 相关的所有请求，包括对资源服务器的访问。客户端不会暴露任何（未加密的）令牌。
令牌中介后端 (TMB)，其中只有后端存储刷新令牌，而访问令牌在客户端公开。
基于浏览器的 OAuth 2.0 客户端，其中 OAuth 2.0 不涉及任何后端。每个令牌都暴露在客户端。
[3] 还特别推荐针对敏感应用采用 BFF 模式：
强烈建议商业应用程序、敏感应用程序和处理个人数据的应用程序采用此架构。
相反，[2]（在整个 RFC 中，特别是在第 4.1 节中）仅指 OAuth 2.0 中不涉及后端的架构，它在概念上对应于上面的基于浏览器的 OAuth 2.0 客户端模式。
但为什么呢？我有以下三个问题：
是否建议对本机应用程序也使用 BFF 模式？
是否有任何正式来源（例如另一个 RFC）来支持您的答案？
为什么 [2] 没有提及 BFF 模式？ 或许是因为原生应用的执行环境比浏览器应用安全得多，在浏览器应用中攻击者可以注入并执行恶意的 JavaScript 代码。但我认为理论上也可以通过二进制补丁或内存编辑等技术对原生应用（尤其是桌面应用）做类似的事情。
是否建议对本机应用程序也使用 BFF 模式？
我想说不是，但我尝试在下面解释一些注意事项。BFF 是一个重载术语。我首先要了解执行环境和你希望 BFF 解决的问题。
对于基于浏览器的应用程序，发布安全 cookie 的 BFF 可确保令牌不会被泄露，从而限制 XSS 漏洞的影响。
对于本机应用程序，我将使用一个示例，其中您希望对返回到设备的令牌保密，因为这也可以成为 BFF 的动机，以防止应用程序或其他方读取 JWT 访问令牌中的数据。
这两种解决方案都可以使用后端组件，但存在很大差异。通常，术语 BFF 用于基于浏览器的应用程序，而不是本机应用程序。
是否有任何正式来源（例如另一个 RFC）来支持您的答案？
基于浏览器的应用程序的 OAuth 介绍指出了浏览器和本机应用程序之间的执行环境存在巨大差异。
没有 IETF 文档讨论用于原生应用的 BFF。但有关OAuth 令牌自检和JWT 响应的文档可能用于需要 BFF 逻辑的原生用例。
为什么 [2] 没有提及 BFF 模式？
为了了解原因，让我们看看 BFF 为基于浏览器的应用程序解决的问题，其中服务器组件协助前端确保其安全性：
BFF 可以发出仅 HTTP 的 cookie，而浏览器无法让 JavaScript 代码使用这些 cookie。JavaScript 也无法看到访问令牌中的内容，从而保证这些数据的机密性。
BFF 可以指示浏览器如何处理 cookie，例如应用
SameSite=strictCORS，以便浏览器只允许从应用程序精确来源中运行的代码发送 cookie。虽然您可以将 BFF 用于本机应用，但您无法隐藏来自应用代码的令牌或 Cookie，也无法指定前端可以将它们发送到何处。相反，本机应用的 BFF 可能会检查不透明的访问令牌，然后将 JWT 访问令牌转发给 API。
概括
我认为 BFF 解决方案是涉及为每个 Web 应用部署一个额外的 Cookie 发布组件的解决方案。对于原生应用，您无需这样做。
如果可能的话，我会在 API 网关中管理诸如令牌自检之类的任务，以将此类逻辑应用于多个 API。有些人将这种类型的解决方案称为 BFF。