Why does PKCE matter if a client already has a secret?

Why This Matters for Security Teams

PKCE matters because a client secret answers a different question: it helps identify the application, but it does not bind an authorization code to the exact client instance that initiated the flow. That distinction becomes critical in browser-based, mobile, desktop, and distributed delivery models where codes can be intercepted, replayed, or redirected. The modern guidance reflected in the OWASP Non-Human Identity Top 10 is to treat code interception risk as a first-order design concern, not an edge case.

For NHI teams, this is the same class of problem that appears when long-lived secrets are assumed to be enough. NHI Mgmt Group research shows how secret exposure becomes operationally durable, especially when credentials live in code or are not rotated quickly, as covered in the Guide to the Secret Sprawl Challenge and the Ultimate Guide to NHIs — Static vs Dynamic Secrets. In practice, many security teams discover the weakness only after an intercepted token or leaked code has already been redeemed elsewhere, rather than through intentional protocol testing.

How It Works in Practice

PKCE adds a proof-of-possession step to the authorization code flow. The client creates a high-entropy code verifier, derives a public code challenge, and sends the challenge with the authorization request. Later, when redeeming the code, the client must present the original verifier. The authorization server checks that the verifier matches the earlier challenge before issuing tokens. That means possession of the authorization code alone is not enough.

This is especially valuable when a client secret is not reliably confidential. Public clients, native apps, SPAs, and many agent-adjacent integration patterns often cannot protect a secret the way a server-side workload can. Even for confidential clients, PKCE narrows the blast radius if the code is intercepted in logs, browser redirects, proxies, or app-embedded webviews. Current guidance suggests treating PKCE as defense in depth rather than a substitute for proper client authentication.

• Use a unique verifier per authorization request.
• Prefer high-entropy, single-use values and short authorization code lifetimes.
• Keep the verifier and challenge generation inside the client boundary, not in shared middleware.
• Continue using a client secret where the client is truly confidential, but do not rely on it as the only binding control.
• Test redirect handling, mobile deep links, and embedded browser flows for interception paths.

Operationally, this aligns with broader NHI guidance on reducing the value of stolen credentials and limiting replay opportunities, including NHI lifecycle controls described in NHI Mgmt Group research on the 52 NHI Breaches Analysis. These controls tend to break down when legacy OAuth implementations, custom redirect handling, or brittle embedded-browser flows prevent the client from reliably preserving the verifier across the full transaction.

Common Variations and Edge Cases

Tighter code binding often increases implementation complexity, requiring organisations to balance stronger interception resistance against compatibility and operational overhead. That tradeoff matters because not every client class is equally capable of protecting a secret or preserving a verifier across redirects.

One common edge case is the confidential client that already has a secret and assumes PKCE is optional. Best practice is evolving, but many platforms now recommend PKCE for all OAuth clients because it protects against code interception even when the secret remains in place. Another edge case is native or browser-based clients that cannot safely store a secret at all; for these, PKCE is not just helpful, it is often the primary binding mechanism.

For teams supporting agentic or automated integrations, the lesson is similar to NHI governance more broadly: static assumptions age poorly. A secret can authenticate a client, but it does not always prove continuity across the full authorization journey. The same pattern appears in secret sprawl and supply-chain compromise, which is why NHI Mgmt Group continues to emphasize short-lived, context-aware controls in research such as the Shai Hulud npm malware campaign and Reviewdog GitHub Action supply chain attack. Where redirect URIs, device handoffs, or custom auth brokers are involved, PKCE can still fail if the code verifier is exposed, stripped, or mishandled in transit.

Related resources from NHI Mgmt Group

• Why do mobile apps need PKCE even when they already use an identity provider?
• Why does MFA usability matter if the security policy is already strong?
• How should security teams implement Client ID Metadata Documents?
• Why do certificates matter for non-human identities?