Why is PKCE `code_verifier` calculated server-side in BFF pattern?

The draft RFC OAuth 2.0 for Browser-Based Applications (published: 17 January 2025) introduces BFF pattern in 6.1. Backend For Frontend (BFF).

Here's the architecture:

The draft says

the JavaScript application triggers a navigation to the BFF (C) to initiate the Authorization Code flow with the PKCE extension (described in Section 6.1.3.1), to which the BFF responds by redirecting the browser to the authorization endpoint (D).

When the user is redirected back, the browser delivers the authorization code to the BFF (E), where the BFF can then exchange it for tokens at the token endpoint (F) using its client credentials and PKCE code verifier.

This implies PKCE code_verifier, code_challenge and code_challenge_method are all calculated and stored server-side, but why?

I have three questions:

In the step (E), client sends an authorization code to backend. However, how can backend identify from which code_verifier this authorization code was derived? I think there is no way because the snippet reads nothing more than an authorization code is sent in the step (E).
Though not mentioned in the draft, this "how-to-identify-code-verifier" problem may be solved by issuing temporal session as HttpOnly cookie in advance and let the client send it in the step (E). Am I correct?
If I'm correct, why bother to use temporal session (such as HttpOnly cookie)? I think just calculating code_verifier, code_challenge and code_challenge_method client-side would completely remove the need for temporal session. In the step (E), the client can send code_verifier in addition to an authorization code to the backend.

Solution

From an OpenID-Connect point of view, the BFF module becomes the client in relation to the Authorization Server. The PKCE is calculated server side because the entire point of the BFF is to shift the authentication logic from the browser to the backend. It is also important to remember that the BFF is usually located in a separate "server/service" from your authorization Server.

Also, PKCE is only applicable when you use the authorization code flow and this is all about authentiating a user and in asecure way exhange the code for the token.

To answer your question.

The BFF is registered as a client in the authorization server and each "BFF authenication attempt gets a different code_verifier generated and its typically stored in a a separate browser cookie through-out the authentication process.
Its often implemented as a temporary HTTP Only cookie.
The big idea with all of this is to avoid any authentication logic in the browser. The browser and mobile applications are public clients. Meaning, they can't handle or keep secrets.

You can find more info about PKCE and OpenID-Connect in: OpenID Connect for Developers