Topic starter
18/08/2026 2:33 pm
TL;DR: PKCE closes a structural OAuth gap by binding each authorization request to its token exchange, so a stolen code cannot be redeemed without the original verifier, according to Ory. That matters because mobile apps, SPAs, and even confidential clients face code interception and injection risks that client secrets alone do not reliably solve.
Editorial analysis by NHI Mgmt Group, based on content published by Ory: “What Is PKCE and Why Does It Matter”.
Key questions
Q: What breaks when OAuth clients use the wrong flow or skip PKCE?
A: When teams choose the wrong grant type or skip PKCE, the authorization process becomes easier to intercept or misuse.
Q: Why does code interception create token risk even when a client secret exists?
A: A client secret only helps when the secret actually stays with the legitimate client.
Q: How do security teams know PKCE is being used correctly?
A: PKCE is being used correctly when every authorization code flow uses a fresh, high-entropy verifier, S256 is the only accepted challenge method, and the verifier is never exposed in URLs or logs.
Practitioner guidance
- Mandate S256 for every authorization code flow Reject plain challenge generation except for tightly justified platform constraints.
- Treat client-side secrets as non-viable Remove embedded client secrets from apps that cannot keep them confidential and assume interception-resistant design must come from PKCE plus redirect URI validation.
- Keep verifiers ephemeral and out of logs Store the code verifier only for the duration of the flow, preferably in memory or platform-secure storage, and never place it in URLs, logs, or persistent storage.
Bottom line: PKCE removes the assumption that a stolen OAuth authorization code is enough to obtain tokens, because the exchange also requires a verifier held by the originating client.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:20 pm
PKCE turns OAuth code redemption into a possession test, not a trust assumption. The authorization server no longer accepts a code as proof that the right client is finishing the flow. It requires evidence that the same party that started the request still holds the verifier. That matters because client-side applications cannot safely keep a secret, so the old confidence model was already broken.
A few things that frame the scale:
- 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
A question worth separating out:
Q: Should organisations require PKCE for confidential clients, or only for public clients?
A: Require it for both. Public clients need PKCE because they cannot rely on a client secret, but confidential clients still benefit because PKCE ties the authorization request to the token request. That reduces the impact of intercepted codes and narrows the assumptions a token endpoint must make about the caller.
👉 Read our full editorial: PKCE makes OAuth code interception a closed risk