OAuth 2.0 中本机应用程序的 BFF 模式？

Question

我已阅读以下所有 RFC：

• [1]：RFC 6749：OAuth 2.0 授权框架

• [2]：RFC 8252：适用于本机应用程序的 OAuth 2.0（请注意，这不仅包括移动应用程序，还包括桌面应用程序。）

• [3]：RFC 草案：基于浏览器的应用程序的 OAuth 2.0

[3] 建议对基于浏览器的应用程序使用以下架构之一：

• Backend For Frontend (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代码，但我认为理论上也可以对原生应用程序做类似的事情（尤其是对于桌面应用程序）通过二进制修补或内存编辑等技术。

Answer 1

OAuth 客户端的最佳实践取决于执行环境。

基于浏览器的应用程序

使用仅限 HTTP 的 cookie 使应用程序的 JavaScript 代码（或任何恶意代码）无法使用它们。这可以限制 XSS 攻击的影响，例如，因为当用户关闭页面时任何攻击都会结束。

原生应用程序

原生应用程序没有同样的保证。如果某种

session cookie

返回到本机应用程序：

• 应用程序代码可以访问cookie。
• 如果应用程序使用恶意库，它还可以访问 cookie 并将其发送到远程主机，以对 API 进行协同攻击。
• 如果不小心，会话 cookie 可能会长期存在并增加漏洞利用的影响。

以下是一些强化本机安全性的技术：

• 使用不透明的访问令牌，以便客户端中的任何代码都无法读取用于 API 的数据。
• 保持访问令牌的生命周期较短，例如 15 分钟。
• 尽可能保护重定向 URI。
• 尽可能使用证明来防止客户端冒充。

冒充威胁

本机应用程序的主要威胁往往是客户端模仿。默认情况下，应用程序充当公共客户端，无法安全地提供客户端凭据。因此，另一个应用程序可能能够充当真正的应用程序并获取令牌。一种部分缓解措施是使用 HTTPS 重定向 URI 来防止恶意客户端接收授权代码。

另一个（重要的）选项是使用现代移动设备的证明功能来获取恶意应用程序无法发送的数字签名，然后在对令牌端点的请求中进行验证。例如，Google Play Integrity 和 Apple App Attest 等服务可以为 apo 提供提供此类签名的证明 JWT。

总结

我希望其中一些方面能够进入 OAuth 本机规范，因为 RFC8252 已经有 8 年历史了。最近值得了解的一个本地 IETF dic 是第一方应用程序的 OAuth。

这些客户端最佳实践通常不会使安全性变得完美，并且需要权衡取舍。