PKCE makes OAuth code interception a closed risk

At a glance

What this is: PKCE is a one-time cryptographic binding for OAuth code flows that prevents intercepted authorization codes from being exchanged without the original verifier.

Why it matters: IAM teams need it because mobile apps, SPAs, and even confidential clients cannot rely on client secrets alone to stop code interception and injection.

Context

PKCE closes a structural weakness in OAuth 2.0 authorization code flows: the platform assumes the party redeeming the code is the same party that started the login. That assumption breaks in mobile apps and browser-based clients because embedded secrets can be extracted, and in redirected flows because a malicious app can intercept the callback.

For identity programmes, the issue is not just token theft. It is whether the authorization server can still trust the entity completing the exchange when the client cannot safely hold a secret. PKCE addresses that by making the token request prove continuity with the original authorization request, which is why modern OAuth deployments now treat it as standard practice.

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. Public clients are harder to protect with a client secret, and authorization codes can be stolen if the flow is not defended properly. The result is weaker assurance that the application receiving tokens is the one that was authorized.

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. In interception and injection scenarios, the attacker either steals the code before redemption or tricks the client into redeeming the wrong code. PKCE adds a separate proof of possession, so the exchange fails unless the verifier matches the original challenge.

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. If any client can complete the exchange without that verifier, the flow is not actually protected.

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.

Technical breakdown

How PKCE binds an authorization request to token exchange

PKCE adds a per-request proof between the authorization request and the token exchange. The client generates a high-entropy code verifier, hashes it with SHA-256 into a code challenge, and sends that challenge with the authorization request. Later, the client presents the original verifier at the token endpoint. The authorization server recomputes the hash and only issues tokens when the values match. That means an intercepted authorization code is not enough on its own, because the verifier never leaves the client until the exchange stage.

Practical implication: Use PKCE as a request-to-exchange binding, not as a substitute for redirect URI validation or session controls.

Why code interception still works without PKCE

OAuth code interception happens when an attacker captures the authorization code before the legitimate client redeems it. Mobile apps and SPAs are especially exposed because they cannot reliably protect a client secret, and custom URL schemes can be shared or hijacked by another app on the device. In that case, the attacker needs only the code and a working token endpoint call to complete the flow. PKCE breaks that replay path by requiring proof of possession of the original verifier, not just the code itself.

Practical implication: Assume any client-side flow without PKCE can be intercepted even if the application looks well-implemented.

Why S256 is the only practical PKCE method

PKCE defines two challenge methods, but only S256 gives actual protection. With S256, the authorization server sees a hashed challenge that cannot be reversed into the verifier. With plain, the verifier and challenge are effectively the same value, so interception defeats the control. That is why modern guidance treats S256 as the default and plain as a fallback only for constrained platforms that truly cannot hash. The security property comes from one-way transformation, not from the existence of the parameter alone.

Practical implication: Require S256 everywhere and reject plain unless a platform exception is documented and narrowly scoped.

Threat narrative

Attacker objective: The attacker wants to convert a stolen authorization code into usable access tokens before the legitimate client redeems it.

1. Entry occurs when a malicious app, browser component, or intercepted redirect captures the OAuth authorization code from a legitimate login flow.
2. Credential access follows when the attacker uses the stolen code to attempt the token exchange without possessing the original verifier.
3. Escalation happens when the attacker turns that one code into valid access tokens and inherits the application's authenticated session context.
4. Impact is unauthorized access to the target application or API resources before the legitimate client can complete the exchange.

Breaches seen in the wild

• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

The structural gap is not weak authentication, it is replayable authorization state. OAuth code interception succeeds when a valid authorization code outlives the context that produced it. PKCE shortens that trust window by binding issuance and exchange with fresh per-request material. The practitioner lesson is that session continuity in OAuth now depends on cryptographic continuity, not just redirect hygiene.

PKCE is now baseline identity plumbing, not an edge-case mobile fix. The article’s strongest implication is that public clients were only the first obvious failure mode. Confidential clients also need the control because code injection attacks abuse the legitimacy of the client that performs the exchange. That shifts PKCE from optional hardening to a default control for modern OAuth governance.

Code interception is a governance problem, not only a protocol problem. If teams allow OAuth flows to run without PKCE, they are accepting an exchange model that can be replayed by any actor able to intercept the redirect. That exposure is especially relevant where agentic and machine-to-machine patterns reuse OAuth concepts at speed, because the control point must remain at token issuance.

PKCE establishes the new assumption for OAuth: the code is not the credential. The credential is the verifier held by the initiating client, and the code is only a temporary reference. That distinction is now central to identity design across public clients, confidential clients, and emerging automated flows that depend on browser-mediated authorization.

From our research library:

• 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
• Read next: NHI Authentication Guide

What this signals

Authorization code interception now belongs in the same control family as secrets handling. Teams should stop treating PKCE as a niche client feature and start treating it as a baseline requirement for any OAuth flow that depends on browser or device redirects. The failure mode is not theoretical, because the intercepted code has value only when the exchange step lacks a cryptographic continuity check.

OAuth governance now has a minimum viable trust chain: code challenge, verifier, state, and nonce each address a different failure. PKCE protects the exchange path, state binds the response to the client session, and nonce protects OpenID Connect token replay. Programmes that implement only one of these controls are still leaving adjacent attack paths open.

PKCE adoption is also a machine-identity signal. As automated systems and agents increasingly use OAuth patterns, the same verifier discipline matters for non-human access flows that cannot safely hold long-lived secrets. That makes PKCE part of broader identity lifecycle design, not just an application security detail.

For practitioners

• Mandate S256 for every authorization code flow Reject plain challenge generation except for tightly justified platform constraints. Make S256 the default policy for mobile apps, SPAs, and server-side clients so the authorization server always receives a one-way challenge instead of a reusable secret.
• 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. This is the correct pattern for public clients.
• 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. The verifier should exist only long enough to finish the token exchange.
• Pair PKCE with state and nonce controls Use PKCE for code interception and injection resistance, state for CSRF binding, and nonce for OpenID Connect token replay protection. These controls solve different parts of the OAuth trust chain and should be deployed together.

Key takeaways

• 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.
• The practical risk is code interception and injection in public clients and even confidential clients, especially when redirect handling can be abused.
• Teams should standardise on S256, keep verifiers ephemeral, and treat PKCE as a default control alongside state and nonce.

Key terms

• Proof Key for Code Exchange: PKCE is an OAuth extension that binds an authorization code to the client instance that started the login flow. It prevents a stolen code from being redeemed without proof of initiation, which is why it is now treated as a baseline control in modern OAuth deployments.
• Code Verifier: A code verifier is a high-entropy secret created by the client during an OAuth login request. The client later presents it during token exchange so the authorization server can prove the same client initiated and completed the flow, reducing the value of intercepted codes.
• Code Challenge: A code challenge is the hashed form of the code verifier sent up front in a PKCE flow. The authorization server stores it and uses it later to confirm the verifier matches, which lets the server validate the exchange without exposing the original secret in transit.
• Authorization Code Interception: An attack where a malicious process steals the authorization code before the intended client can redeem it. The threat is strongest in public clients and redirect environments that can be observed or hijacked. PKCE is the control designed to prevent the stolen code from being useful.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.