为什么 PKCE `code_verifier` 是在 BFF 模式下在服务器端计算的？

Question

RFC 草案基于浏览器的应用程序的 OAuth 2.0（发布日期：2025 年 1 月 17 日）在 6.1 中引入了 BFF 模式。前端的后端 (BFF).

这是架构：

草案说

JavaScript 应用程序触发到 BFF (C) 的导航，以使用 PKCE 扩展（第 6.1.3.1 节中所述）启动授权代码流程，BFF 通过将浏览器重定向到授权端点 (D) 来响应该流程。

当用户重定向回来时，浏览器会传递 授权码给 BFF (E)，然后 BFF 可以交换它 使用其客户端凭据在令牌端点 (F) 处获取令牌，并且 PKCE 代码验证器。

这意味着 PKCE

code_verifier

、

code_challenge

和

code_challenge_method

都是在服务器端计算和存储的，但为什么呢？

我有三个问题：

• 在步骤(E)中，客户端向后端发送授权码。但是，后端如何识别这个授权码是从哪个

  code_verifier

  导出的呢？我认为没有办法，因为代码片段读取的只是在步骤 (E) 中发送的授权代码。

• 虽然草案中没有提到，但这个“如何识别代码验证器”问题可以通过提前将临时会话发布为

  HttpOnly

  cookie并让客户端在步骤（E）中发送来解决。我说得对吗？

• 如果我是正确的，为什么还要费心使用临时会话（例如

  HttpOnly

  cookie）？我认为仅在客户端计算

  code_verifier

  、

  code_challenge

  和

  code_challenge_method

  就可以完全消除对临时会话的需要。在步骤(E)中，除了授权码之外，客户端还可以向后端发送

  code_verifier

  。

Answer 1

从 OpenID-Connect 的角度来看，BFF 模块成为与授权服务器相关的客户端。 PKCE 是在服务器端计算的，因为 BFF 的全部目的是将身份验证逻辑从浏览器转移到后端。同样重要的是要记住，BFF 通常位于与授权服务器不同的“服务器/服务”中。

此外，PKCE 仅在您使用授权代码流程时适用，这都是关于对用户进行身份验证并以安全的方式交换令牌代码。

回答你的问题。

1. BFF 在授权服务器中注册为客户端，每次“BFF 身份验证尝试都会生成一个不同的 code_verifier，并且在整个身份验证过程中它通常存储在单独的浏览器 cookie 中。

2. 它通常作为临时 HTTP Only cookie 实现。

3. 所有这一切的重要想法是避免浏览器中的任何身份验证逻辑。浏览器和移动应用程序是公共客户端。意思是，他们无法处理或保守秘密。

您可以在以下位置找到有关 PKCE 和 OpenID-Connect 的更多信息：面向开发人员的 OpenID Connect