Why is PKCE "RECOMMENDED" for authorization codes with confidential clients?

Question

Section 2.1.1 of IETF's OAuth 2.0 Security Best Current Practice begins as follows:

Clients MUST prevent injection (replay) of authorization codes into the authorization response by attackers. Public clients MUST use PKCE [RFC7636] to this end. For confidential clients, the use of PKCE [RFC7636] is RECOMMENDED. With additional precautions, described in Section 4.5.3.2, confidential clients MAY use the OpenID Connect "nonce" parameter and the respective Claim in the ID Token [OpenID] instead. In any case, the PKCE challenge or OpenID Connect "nonce" MUST be transaction-specific and securely bound to the client and the user agent in which the transaction was started.

I understand why "public clients MUST use PKCE;" RFC 7636 explains why it is necessary for public clients very clearly. However, why is PKCE "RECOMMENDED" for confidential clients? I read the RFC and was not able to find the rationale for that.

Answer 1

PKCE provides some interesting properties that improve OAuth security:

• It binds the authorization code to the session. This protects against injecting another authorization code in the URL in case the attacker has only access to the authorization response, code_challenge_method is S256.
• Checking the PKCE code_challenge is up to the authorization server. In contrast to checking state and nonce, which is up to the client. Given a cryptographically secure code_verifier, this protects against clients not properly checking state and nonce.

Above might be edge cases, but supporting and using PKCE is not complicated, so this might be the reason for recommending the use of it even for confidential clients.