To understand PKCE, it helps to first understand the exact moment in an OAuth login where things can quietly go wrong.

In a standard OAuth 2.0 Authorization Code flow, after a user logs in and approves access, the Authorization Server doesn’t hand the client its final access token right away. Instead, it first redirects the user’s browser or device back to the client application carrying a short-lived value called an authorization code. The client is then expected to take that code and exchange it, in a separate step, for the actual access token. This two-step design exists so tokens never have to travel through the most exposed part of the journey — the browser’s visible redirect.

On a traditional web server, this design was already quite safe, because the redirect lands on a server the developer controls, and the code exchange happens over a private, server-to-server channel. But mobile operating systems and desktop platforms complicate the picture. On these platforms, the “redirect” that carries the authorization code back to the app often relies on a custom URL scheme or a shared mechanism the operating system uses to figure out which installed app should receive it. And here’s the catch: more than one app installed on the same device can sometimes register to handle the very same custom scheme.

A similar risk exists on the web, in a slightly different shape. A single-page application’s redirect address is a normal web URL rather than a custom scheme, but the authorization code still passes briefly through the browser’s address bar and browser history before the application’s own code reads and processes it. Browser extensions, malicious scripts, or careless client-side logging could potentially capture that value during this brief window. PKCE closes this path too, using the same underlying mechanism regardless of whether the interception risk comes from a competing mobile app or from something observing the browser.

This exact scenario — a legitimate authorization code being intercepted by a second, malicious application — is what PKCE, short for Proof Key for Code Exchange and pronounced “pixy,” was specifically designed to close. It does this without requiring the client to hold any secret at all, which matters enormously for public clients like mobile apps and browser-based apps that, as covered in earlier tutorials, can never truly keep a secret hidden.

PKCE was formally published in 2015 as an extension to OAuth 2.0, growing directly out of real-world reports of this interception pattern being exploited on mobile platforms. What started as an optional add-on aimed narrowly at native app developers has, over the following decade, been folded into mainstream security guidance so thoroughly that many current OAuth implementations now treat it as mandatory rather than optional — a trajectory that mirrors how several other “recommended extras” in web security eventually became baseline expectations once their value became clear in practice.

PKCE introduces exactly three new terms to OAuth. Once these are clear, the rest of PKCE is just “when do these get used.”

The relationship between these two values is deliberately one-directional. Given a code verifier, anyone can quickly compute the matching code challenge. But given only a code challenge, there is no practical way to work backward and recover the original code verifier — the transformation is designed to make that computationally unfeasible. This one-way property is the entire reason PKCE works: the code challenge can be sent early, in a place an attacker might be able to see, without giving away the secret it’s based on.

It’s worth understanding, in plain terms, what “one-way transformation” actually means here, since it’s the mathematical property the entire mechanism rests on. A hashing function takes an input of any length and produces a fixed-size output in a way that’s extremely easy to compute in one direction — from input to output — but effectively impossible to reverse — from output back to input — even with significant computing power. This is a similar principle to how a shredded document can’t practically be reconstructed by looking only at the shredded pieces, even though shredding it in the first place was quick and simple. S256 applies exactly this kind of one-way hashing function to the code verifier to produce the code challenge.

A few common misunderstandings about PKCE are worth addressing directly.

PKCE doesn’t introduce new roles or new servers — it adds two extra pieces of data layered onto the existing Authorization Code flow.

flowchart LR
    C["Client
generates code_verifier"] -- "derives" --> CH["code_challenge
(one-way transform)"]
    C -- "1: sends code_challenge" --> AS["Authorization Server"]
    U["Resource Owner"] -- "logs in & approves" --> AS
    AS -- "2: returns authorization code" --> C
    C -- "3: sends code_verifier + code" --> AS
    AS -- "4: checks match, then issues tokens" --> C
        

Everything else about the surrounding architecture — the four core OAuth roles, the redirect-based login, the eventual call to the Resource Server — stays exactly the same as any other Authorization Code flow. PKCE is best understood as a small, self-contained addition layered on top, rather than a separate flow of its own. This is part of why it was possible to add PKCE to the OAuth ecosystem without requiring a completely new specification or breaking existing implementations.

This additive nature also means PKCE fits cleanly alongside every client type discussed in earlier tutorials. A confidential client’s backend can generate a code verifier just as easily as a public client’s mobile app can — the mechanism doesn’t care whether the party generating it also happens to have a client secret. This is precisely why current guidance increasingly treats PKCE as something every Authorization Code flow should include by default, rather than as a special case reserved only for clients that can’t authenticate themselves any other way.

This layered, additive design has a practical benefit beyond security: it made PKCE straightforward for existing OAuth libraries and Authorization Servers to adopt. Because PKCE only adds two extra fields to messages that already existed, rather than requiring an entirely new type of request or response, most OAuth software could support it through a relatively small update. This is a meaningful part of why PKCE spread so quickly across the ecosystem — the barrier to adoption was low, while the security benefit was significant.

Here is the complete sequence, from the moment a user taps “log in” to the moment tokens are issued.

sequenceDiagram
    participant App as Client App
    participant User as Resource Owner
    participant AS as Authorization Server
    participant RS as Resource Server

    App->>App: Generate code_verifier, derive code_challenge
    App->>AS: Redirect with code_challenge + method
    AS->>User: Show login and consent screen
    User->>AS: Approve requested scopes
    AS->>App: Redirect back with authorization code
    App->>AS: Send code + original code_verifier
    AS->>AS: Recompute transform, compare to stored code_challenge
    AS->>App: Tokens issued only if values match
    App->>RS: API request with access token
    RS->>App: Return requested data
        

If an attacker intercepted the authorization code somewhere between steps six and seven — for example, through the malicious-app scenario described in Chapter 1 — they would still be missing the code verifier from step one, which never left the legitimate app. Attempting to redeem the stolen code without the matching verifier fails at step eight, and no tokens are ever issued to the attacker.

It’s worth pausing on how little burden this places on the parties involved. The end user experiences no visible difference at all — no extra screen, no additional step, no new prompt to approve. The Authorization Server does slightly more bookkeeping, briefly remembering which code challenge belongs to which authorization code until that code is redeemed or expires. The client does slightly more work generating and later resubmitting a value it already had sitting in memory. None of these additions meaningfully slow down the login experience, which is a large part of why PKCE was able to spread so widely without pushback from either developers or end users.

Unlike a client secret, the code verifier is intentionally short-lived and disposable — its entire life fits inside a single login attempt.

flowchart TD
    A["New login attempt begins"] --> B["Fresh code_verifier generated"]
    B --> C["code_challenge derived and sent"]
    C --> D["User completes login elsewhere"]
    D --> E["Authorization code returned"]
    E --> F["code_verifier sent to redeem code"]
    F --> G{"Match confirmed?"}
    G -- Yes --> H["Tokens issued, code_verifier discarded"]
    G -- No --> I["Request rejected, no tokens issued"]
        

This short lifecycle is a deliberate strength, not a limitation. Because a brand-new code verifier is generated for every login attempt, there is nothing long-lived for an attacker to steal ahead of time and reuse later — unlike a client secret, which stays valid across countless logins until it’s manually rotated. Once a login attempt finishes, successfully or not, its code verifier is simply discarded and never referenced again.

This also explains why PKCE doesn’t need anything like the rotation schedules discussed for client secrets in earlier tutorials. A client secret is valuable precisely because it’s reused across many logins, which is exactly why it needs periodic rotation to limit the damage from an eventual leak. A code verifier, by contrast, is worthless the moment its one login attempt concludes, whether that attempt succeeded or failed — there’s nothing left to rotate, because nothing persists to be reused.

PKCE was designed around a specific threat model. Understanding exactly what it does and doesn’t cover helps teams avoid over-relying on it for unrelated risks.

It’s also worth being precise about what “the client device” means in the interception scenario from Chapter 1, since it clarifies the boundary of what PKCE protects. The threat isn’t that the operating system itself is malicious — it’s that the operating system’s mechanism for routing a redirect to the correct app can, in certain configurations, be ambiguous between two apps that both claim the same scheme. PKCE doesn’t try to fix that underlying ambiguity in how operating systems route redirects; it simply ensures that even if the routing goes to the wrong app, that wrong app still can’t do anything useful with what it received.

PKCE is widely considered close to a “free win” in OAuth security, but it’s still worth weighing its costs honestly.

It’s useful to compare this trade-off to other security measures teams commonly adopt. Some protections, like requiring hardware security keys for every login, offer strong security but at a real cost to user convenience and implementation effort. PKCE sits at almost the opposite end of that spectrum: it happens entirely behind the scenes, adds no visible step for the end user, and typically requires only a small, one-time implementation effort from developers using a modern OAuth library. This unusually favorable ratio of protection gained to cost incurred is the main reason PKCE has seen such broad, fast adoption across the industry compared to many other security recommendations.

Teams running an Authorization Server can watch a handful of PKCE-specific signals to catch problems early.

Dashboards that surface these metrics are most useful when broken down by client, rather than shown only as one aggregate number across an entire system. A single client suddenly showing a spike in PKCE verification failures is a much stronger, more actionable signal than a small overall increase spread thinly across dozens of unrelated clients, which could just as easily be noise. Teams that build alerting around per-client thresholds, rather than system-wide averages, tend to catch targeted interception attempts against one specific application far earlier than teams relying on aggregate dashboards alone.

It’s also worth correlating PKCE-related metrics with other signals already being collected, such as unusual geographic patterns in login attempts or a sudden change in which devices are associated with a given user account. A PKCE verification failure occurring alongside a login attempt from an unfamiliar location paints a very different picture than the same failure happening alongside a routine, expected login — treating these signals together, rather than each in isolation, tends to produce far fewer false alarms while still catching genuine problems quickly.

Some approaches to implementing PKCE reflect careful engineering; others accidentally recreate the very gap PKCE was meant to close.

A condensed checklist for implementing PKCE the way it was intended to be used.

It’s also worth building the habit of testing the failure path, not just the success path, when implementing PKCE for the first time. Deliberately sending a mismatched code verifier during development and confirming that the Authorization Server correctly rejects the request is a simple way to verify the protection is actually wired up correctly, rather than only ever exercising the flow where everything matches and quietly assuming the check is happening. Teams that skip this verification step sometimes discover, only much later, that a misconfiguration had silently disabled the PKCE check entirely while every legitimate login continued working as expected.

PKCE has quietly become part of the everyday login experience for a huge range of applications.

No. HTTPS protects data while it travels across the network from being read or altered by anyone in between, while PKCE protects against a different problem — a legitimate authorization code ending up in the wrong hands after it arrives. Both are needed, and neither substitutes for the other.

The client application generates it, entirely on its own, with no involvement from the user or the Authorization Server. The Authorization Server only ever sees the code challenge upfront and the code verifier at the very end, when it checks that the two match.

PKCE was specifically designed for the Authorization Code flow, since that’s the flow involving a redirect and a code that could be intercepted. Grant types without that redirect step, like the Client Credentials flow described in earlier tutorials, don’t involve PKCE because there’s no comparable code-interception risk to address.

The client simply cannot use it against that server, and would instead rely on other protections such as exact redirect URI matching and, where possible, client authentication. Today, PKCE support is extremely widespread, so this situation mostly comes up with older or custom-built Authorization Servers.

Yes. PKCE protects the authorization code exchange step specifically — it doesn’t do anything to protect an access token after it’s already been issued. Short token lifetimes, careful storage, and scope minimization, covered in earlier tutorials, remain just as important.

For a genuinely public client, there was never a safe way to use a client secret in the first place, so PKCE simply fills that gap. For a confidential client, PKCE is an addition, not a replacement — the client secret or other authentication method is still used and still matters.

Long enough to be effectively unguessable through random chance — the specification defines an acceptable length range, and most OAuth libraries handle generating an appropriately sized value automatically, so developers rarely need to choose this manually.

Not meaningfully. An abandoned code verifier was never sent anywhere and has no associated authorization code that reached the redemption step, so it simply becomes irrelevant once the client discards it — there’s nothing for an attacker to exploit from an incomplete attempt.

In practice, no. Because code verifiers are generated from a sufficiently large random space, the odds of two independent apps ever producing an identical value are astronomically small — far smaller than the odds of any other part of a typical security system failing first.

No noticeable difference. Generating a random value and applying a hash to it are both extremely fast operations for a modern device, and the extra data sent is tiny compared to everything else already exchanged during a typical login — users experience no perceptible delay from PKCE being present.

PKCE closes a specific, real gap in the OAuth 2.0 Authorization Code flow: the possibility that a legitimate authorization code could be intercepted by the wrong party on a shared device or an exposed network path. By having the client generate a private, disposable code verifier before the flow begins, sending only a one-way scrambled version ahead of time, and revealing the original value only at the final redemption step, PKCE ensures that possessing a stolen code alone is never enough. It requires no shared secret, making it naturally suited to mobile apps and browser-based clients that can never truly keep one hidden, while remaining a valuable, low-cost addition even for confidential clients that already authenticate themselves through other means. What began as a recommendation aimed mainly at native apps has become, in current practice, close to a universal default across the entire OAuth ecosystem — a rare example of a security improvement that asked almost nothing of developers or users while meaningfully closing a real-world gap that had already been exploited before the fix existed.