When should you choose PKCE over the classic authorization code flow in Spring Security 7's Authorization Server?

PKCE (Proof Key for Code Exchange) adds a client-generated code_verifier/code_challenge pair to the authorization code flow, so that even if an attacker intercepts the authorization code, they can't exchange it for a token without also having the original verifier the client held onto locally.

The classic authorization code flow, without PKCE, relies on a confidential client secret to prove the token-exchange request is legitimate - that works fine for a traditional server-side application that can keep a secret safely on the backend, out of reach of end users. It breaks down for public clients that can't store a secret securely: single-page applications running entirely in the browser, and native mobile apps whose binaries can be decompiled to extract any embedded secret. For those clients, PKCE is not just recommended but effectively mandatory, since there is no secret to protect in the first place.

Because Spring Security 7's Authorization Server now enables PKCE and Dynamic Client Registration by default, the framework's own defaults already steer every client - public or confidential - toward the safer configuration unless a team deliberately opts out.