OAuth PKCE binds a code exchange; client authentication identifies the client

PKCE associates an authorization request with a later code exchange through a transaction-specific verifier and challenge. Client authentication establishes that the requester can present the registered client credential. A reusable client credential does not provide the same per-transaction binding as PKCE.

Illustrative contrast: a native application cannot safely treat a shared secret embedded in every installed copy as a confidential application credential. A server-side application may protect a private client credential, yet still use PKCE to bind each authorization-code exchange to the initiating transaction.

RFC 9700 requires PKCE for public clients and recommends it for confidential clients. Use a maintained OAuth implementation, fresh transaction-specific values, and the S256 challenge method. Keep the server's actual enforcement and metadata in scope; merely adding parameters to the client is insufficient.

Do not conclude that PKCE alone solves redirect validation, issuer confusion, token scope, transport protection, or all CSRF concerns. Those checks remain part of the complete flow.

Limit: this is a distinction between protocol mechanisms, not a deployment audit. Whether a particular client can keep credentials confidential is an architectural property, not a label that can be assigned by configuration alone.