Glossary / Proof Key for Code Exchange

Proof Key for Code Exchange

What is Proof Key for Code Exchange (PKCE)

AI agents can spin up anywhere, which might be in the cloud, on edge devices, or even in public networks. This level of ubiquity makes protecting their authentication flows a challenge. Storing long-term client secrets in those environments is risky. Proof Key for Code Exchange (PKCE) solves that problem by letting agents prove their identity with a one-time secret that can’t be reused or stolen.

PKCE (pronounced “pixy”) is an extension to the OAuth 2.0 protocol that protects the authorization code grant flow from interception attacks. It adds an extra handshake to the process, ensuring that only the client that started an OAuth flow can finish it, even if an attacker manages to capture the authorization code in transit.

Why PKCE matters

In a standard OAuth 2.0 authorization code flow, the authorization server returns a short-lived code to the client after user consent. The client then exchanges that code for an access token. But if an attacker intercepts that code, either through a malicious app, misconfigured redirect, or exposed logs, they can exchange it for a valid token and gain access to protected data.

PKCE closes this gap by tying the authorization code to a unique, per-request “code verifier” known only to the client. Without the verifier, intercepted codes are worthless. This makes PKCE particularly important for public clients, such as mobile apps, single-page applications, and AI agents that operate in less controlled environments.

How PKCE works

Behind every secure OAuth handshake is a simple question: “Are you really who you say you are?” PKCE answers that question by turning each login attempt into a one-time puzzle that only the rightful client can solve. It essentially makes it impossible for an impostor to finish what they didn’t start.

• Generate a code verifier
  The client creates a cryptographically random string at least 43 characters long. This is the secret “proof” linking the start and end of the OAuth exchange.
• Create a code challenge
  The verifier is transformed into a code challenge using one of two methods:
  • S256 — SHA-256 hash of the verifier, base64URL-encoded (recommended).
  • Plain — The unmodified verifier (only used when S256 isn’t possible).
• Send the challenge with the authorization request
  The challenge and method are sent to the authorization server when the OAuth flow begins.
• Exchange code for token
  The client sends the original verifier when redeeming the authorization code for an access token.
• Server validation
  The server applies the same transformation to the verifier and compares it to the stored challenge. If they match, it issues the token; if not, it rejects the request.

This extra check ensures that only the client who generated the verifier can complete the flow.

PKCE benefits

In security, the best wins are the ones an attacker never sees coming. PKCE makes intercepted codes useless, eliminating the need for static secrets so that every exchange is tied to a single, verifiable moment in time.

• Stops code interception attacks . Even if an attacker captures the authorization code, they can’t use it without the verifier.
• No static secrets . Ideal for public or dynamic environments where storing a long-term secret is unsafe.
• Wide support . PKCE is compatible with most OAuth servers and libraries.
• Dynamic per-request proof . Reduces the risk of replay attacks by generating a new verifier for every request.
• Backward compatible . Works with servers that don’t require PKCE, though enforcing it server-side is best practice.

Best practices for PKCE

PKCE is only as strong as the way you use it. Skip the shortcuts, and it becomes a near-bulletproof safeguard against code interception. Follow a few key rules, and you’ll have an OAuth flow that’s fast, reliable, and far less tempting to attackers.

• Always use S256 instead of plain whenever possible.
• Generate a new, high-entropy verifier for each OAuth request.
• Store the verifier securely until the token exchange is complete.
• Enforce PKCE server-side to prevent downgrade attacks.
• Use PKCE alongside HTTPS, client secrets, and access controls for layered security.

PKCE in AI agent authentication

Strata’s Maverics platform uses PKCE to authenticate AI agents securely without pre-shared secrets. This helps keep OAuth sign-ins safe, even when agents run in open or large-scale environments. It ensures that no one can steal or tamper with the codes used to log in. When paired with zero trust security, Maverics can keep agent connections safe and easy to manage.