为何在BFF模式中PKCE的code_verifier要在服务端生成？

针对你提到的IETF 2025年1月发布的《OAuth 2.0 for Browser-Based Applications》RFC草案6.1节的BFF模式，三个问题的解答如下：

1. 步骤E中客户端仅发送授权码，服务端如何关联对应的code_verifier？ #

BFF在启动授权流程时，会生成code_verifier、code_challenge及code_challenge_method，同时创建一个用户会话（基于会话ID），并将这些PKCE参数绑定到该会话中存储在服务端（比如Redis、内存会话存储）。当用户完成授权返回，浏览器携带授权码请求BFF时，BFF通过用户的会话标识（通常由Cookie传递）找到对应会话，从而取出绑定的code_verifier用于后续令牌交换。

2. 用HttpOnly临时会话Cookie解决关联问题是否可行？ #

完全可行，这也是BFF模式下的标准实践：

• BFF在第一次收到前端启动授权的请求时，生成HttpOnly临时会话Cookie返回给前端，同时将code_verifier与该会话ID关联存储。
• 前端后续跳转授权端点、返回BFF时，浏览器会自动携带这个Cookie，BFF通过Cookie中的会话ID就能匹配到对应的code_verifier。
• HttpOnly属性能防止前端JS读取Cookie，避免XSS攻击窃取会话信息，提升流程安全性。

3. 为何不直接让客户端计算PKCE参数并随授权码发送？ #

这涉及BFF模式的核心设计目标和PKCE的防护逻辑：

• PKCE的防护意义会失效：PKCE原本是为了保护纯前端这类公共客户端，通过code_verifier确保只有发起授权的主体能交换令牌。如果让前端计算并持有code_verifier，该参数可能被XSS攻击窃取（存在内存或本地存储），攻击者拿到授权码和code_verifier后就能直接换取令牌，PKCE的防护作用彻底丧失。
• 违背BFF模式的核心设计：BFF的核心是把OAuth敏感操作（令牌交换、令牌存储）移到受信任的后端，让前端完全接触不到code_verifier和最终的访问令牌，从根源上减少前端暴露敏感信息的风险。
• 客户端凭证的安全要求：BFF作为OAuth客户端，其客户端凭证（client_id/client_secret）存储在服务端，不能暴露给前端。令牌交换必须由BFF完成，而PKCE参数由BFF生成和存储，能保证整个交换流程的完整性和安全性。

内容的提问来源于stack exchange，提问作者ynn