PKCE is now the baseline for secure OAuth code flows

At a glance

What this is: This is a developer guide to Proof Key for Code Exchange, showing how PKCE secures OAuth Authorization Code flows by binding the token exchange to a per-request verifier.

Why it matters: It matters because OAuth implementations underpin both human sign-in and machine-facing access patterns, and weakening the code exchange step can expose tokens across IAM and workload identity programmes.

👉 Read WorkOS' guide to PKCE in OAuth 2.1

Context

PKCE is a protection layer for OAuth Authorization Code flows that stops intercepted codes from being redeemed without the original verifier. The article argues that this is no longer a niche safeguard for public clients alone, because OAuth 2.1 makes PKCE mandatory across application types.

For identity teams, the issue is broader than one auth pattern. When code exchange is not bound to the initiating client, the trust boundary is too loose for modern app, API, and workload access flows, especially where mobile, browser, proxy, or library behaviour can expose the code in transit.

Key questions

Q: How should security teams implement PKCE across OAuth applications?

A: Security teams should require PKCE for every Authorization Code flow, use S256 exclusively, and verify that client libraries generate a fresh verifier per login attempt. They should also test redirect handling, token exchange logic, and environment-specific SDK defaults so that no integration silently bypasses the verifier step.

Q: Why do confidential OAuth clients still benefit from PKCE?

A: Confidential clients still benefit because a client secret does not fully protect the authorization response path. PKCE binds the token exchange to the original request, which helps defend against code injection, tampering, and intermediary exposure that can occur before the secret ever matters.

Q: What breaks when PKCE is not enforced in OAuth 2.1?

A: Without PKCE, intercepted authorization codes can be redeemed by an attacker, and redirect tampering becomes easier to exploit. The result is that code possession becomes too powerful, especially in browser, mobile, and proxy-mediated flows where front-channel exposure is realistic.

Q: Who is accountable when an OAuth implementation allows weak code exchange controls?

A: Application owners, identity architects, and platform teams share accountability because PKCE is a protocol control that must be enforced in both configuration and implementation. The governance expectation is to make the safer path the default, then prove that every client and library follows it consistently.

Technical breakdown

How PKCE binds the authorization code to the client

PKCE adds a cryptographic proof step to the OAuth Authorization Code Grant. The app generates a random code verifier, hashes it into a code challenge, and sends that challenge during the authorization request. Later, when the authorization code is exchanged for tokens, the client must present the original verifier. The authorization server hashes the verifier and checks that it matches the stored challenge. Because the verifier is never sent in the front channel, an intercepted authorization code is useless without it. This changes the security property of the flow from simple possession of the code to possession plus proof of initiation.

Practical implication: Require PKCE on every Authorization Code flow and validate that libraries do not silently skip the verifier exchange.

Why confidential apps still need PKCE in OAuth 2.1

PKCE is not only for public clients such as SPAs and mobile apps. Even server-side applications can face code injection, redirect tampering, malicious browser extensions, or proxy-related exposure that the client secret alone does not fully address. The article’s key point is that a client secret protects the token endpoint, but PKCE protects the authorization initiation itself by binding the response to the original request. OAuth 2.1 formalises that distinction by treating PKCE as a universal requirement rather than a client-type workaround.

Practical implication: Treat PKCE as mandatory for confidential clients too, and review auth libraries for explicit S256 enforcement.

Common PKCE implementation failure modes

The most common mistakes are operational, not theoretical. Reusing a code verifier turns the flow into a replay risk. Using the plain method weakens the protection because the challenge is no longer a strong one-way proof. Failing to preserve the verifier until exchange completion breaks the flow, while assuming an SDK handles PKCE automatically can leave entire integrations unprotected. These are implementation lapses at the boundary between application code, identity libraries, and token exchange behaviour, which is why they often survive code review unnoticed.

Practical implication: Test PKCE behaviour in every client and SDK combination, and fail builds when plain or verifier reuse is detected.

NHI Mgmt Group analysis

PKCE is now part of the trust boundary, not an optional enhancement. The article shows that the security property of OAuth Authorization Code flows changes once the verifier is required at exchange time. That means identity programmes can no longer treat code interception as an edge case handled by client secrecy alone. The practitioner implication is that protocol hardening has moved into baseline access governance.

Code interception and code injection are different failure modes, and PKCE addresses both by design. Interception is the classic front-channel theft problem, while injection covers tampered or substituted authorization codes during redirects and intermediary handling. OAuth teams should read that as a reminder that a single token exchange can fail in more than one place. The practitioner implication is to validate the full authorization journey, not just the final token call.

Universal PKCE simplifies governance across public and confidential clients. When one control applies everywhere, policy exceptions shrink and audit language becomes clearer. That matters for IAM teams running mixed estates of SPAs, mobile apps, server apps, and federation brokers. The practitioner implication is that standardisation is a governance gain, not just a protocol cleanup.

OAuth 2.1 formalises what mature identity programmes were already converging on. The article reflects a broader pattern in IAM where formerly optional safeguards become default expectations once attack paths are well understood. That aligns with NIST Cybersecurity Framework 2.0 thinking around protect and govern functions, and with zero trust principles that require stronger proof at every access step. The practitioner implication is to align migration work with policy, not wait for legacy implementations to age out.

PKCE exposes a broader assumption about delegated identity: the client that starts the flow should be the client that finishes it. That assumption is designed for predictable, human-paced or app-paced request handling. It fails when redirection, intermediaries, or client-side exposure allow another party to complete the exchange. The practitioner implication is to treat proof binding as a core identity control, not a convenience feature.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means identity controls often operate without complete state awareness.
• That visibility gap is why lifecycle discipline matters, so teams should also review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs alongside OAuth policy updates.

What this signals

PKCE normalises a wider identity-security pattern: proof binding is becoming a default expectation wherever delegated access crosses a channel boundary. For IAM and platform teams, the practical signal is that library choice now affects control assurance, so identity policy must extend into application engineering standards and deployment review.

OAuth 2.1 does not create a new risk model, but it does make the old exception language harder to defend. Teams that still classify PKCE as optional usually have inconsistent enforcement, which is exactly how weak defaults survive across SPAs, mobile apps, and server-side integrations.

With 71% of NHIs not rotated within recommended time frames, according to the Ultimate Guide to NHIs, the broader lesson is that identity assurance failures often come from implementation drift, not just missing policy.

For practitioners

• Enforce S256-only PKCE across all OAuth clients Reject plain method usage in policy, linting, and CI checks. Make S256 the default and block any client registration that does not support it consistently across environments.
• Verify verifier lifecycle handling in every SDK Test that the code verifier is generated per request, stored only for the duration of the exchange, and discarded immediately after token issuance. Confirm that libraries do not reuse verifiers across sessions.
• Review redirect and proxy exposure paths Inspect browser extensions, reverse proxies, mobile handoff flows, and redirect handlers for code leakage points. PKCE reduces exploitability, but it does not eliminate exposure of the authorization code itself.
• Align OAuth policy with OAuth 2.1 defaults Update internal standards so new integrations treat PKCE as mandatory rather than conditional. Remove legacy guidance that still separates public and confidential clients for PKCE decisions.

Key takeaways

• PKCE turns OAuth authorization code redemption into a proof-bound exchange, which sharply reduces the value of intercepted codes.
• OAuth 2.1 makes PKCE a baseline expectation for all clients, so exceptions now create governance and audit friction.
• Teams should enforce S256, test SDK defaults, and treat verifier lifecycle handling as part of identity control assurance.

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.
• Authorization Code Grant: The Authorization Code Grant is an OAuth flow where an application receives a short-lived code and exchanges it for tokens at the authorization server. It is widely used because it keeps tokens off the front channel and supports stronger control points such as PKCE and redirect validation.
• 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.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by WorkOS: What is PKCE and why every OAuth app should use it. Read the original.