基于浏览器的应用程序的RFC OAuth 2.0 草案（发布日期：2025 年 1 月 17 日）在 6.1 中引入了BFF 模式。前端的后端 (BFF)。
架构如下：
草案称
JavaScript 应用程序触发到 BFF（C）的导航，以使用 PKCE 扩展启动授权码流（如第 6.1.3.1 节所述），BFF 通过将浏览器重定向到授权端点（D）来做出响应。
当用户被重定向回来时，浏览器会将授权码传递给 BFF（E），然后 BFF 可以使用其客户端凭据和 PKCE 代码验证器在令牌端点（F）将其兑换为令牌。
这意味着 PKCE code_verifier，code_challenge并且code_challenge_method都是在服务器端计算和存储的，但是为什么呢？
我有三个问题：
在步骤 (E) 中，客户端向后端发送授权码。但是，后端如何识别
code_verifier此授权码是从哪里派生出来的？我认为没有办法，因为代码片段只显示在步骤 (E) 中发送了授权码。虽然草案中没有提到，但这个“如何识别代码验证器”的问题可以通过
HttpOnly提前将临时会话作为 cookie 发出并让客户端在步骤 (E) 中发送来解决。我说得对吗？如果我是对的，那么为什么要使用临时会话（例如
HttpOnlycookie）呢？我认为只需计算code_verifier和客户端就可以完全消除对临时会话的需求。在步骤 (E) 中，客户端除了授权码之外还可以向后端发送。code_challengecode_challenge_methodcode_verifier
从 OpenID-Connect 的角度来看，BFF 模块成为与授权服务器相关的客户端。PKCE 是在服务器端计算的，因为 BFF 的整个目的是将身份验证逻辑从浏览器转移到后端。同样重要的是要记住，BFF 通常位于与授权服务器不同的“服务器/服务”中。
此外，PKCE 仅在您使用授权码流时适用，这完全是关于对用户进行身份验证并以安全的方式交换令牌的代码。
回答你的问题。
BFF 在授权服务器中注册为客户端，每次“BFF 身份验证尝试都会生成不同的 code_verifier，并且通常在整个身份验证过程中将其存储在单独的浏览器 cookie 中。
它通常作为临时的 HTTP Only cookie 实现。
所有这些的重点是避免浏览器中的任何身份验证逻辑。浏览器和移动应用程序是公共客户端。这意味着它们无法处理或保守秘密。
您可以在以下位置找到有关 PKCE 和 OpenID-Connect 的更多信息：面向开发人员的 OpenID Connect