OAuth PKCE

In the OAuth authorization code flow, the user signs in at the provider, and the provider redirects back to the app with a short-lived authorization code. The app then swaps the code for an access token. A server-side app proves its identity at that swap with a client secret. Mobile apps, desktop apps and single-page web apps can't keep a secret, because anyone can unpack them. On a phone, another app registered for the same URL scheme could intercept the redirect, take the code and redeem it first. RFC 7636, published in September 2015, calls this the authorization code interception attack and defines PKCE to stop it.

1. Before sign-in, the app generates a random code_verifier: 43 to 128 characters from letters, digits and -._~.
2. It sends a code_challenge with the authorization request. With the S256 method, that's the base64url-encoded SHA-256 hash of the verifier.
3. At the token request, the app sends the original verifier. The server hashes it and compares the result with the challenge it stored. If they don't match, there's no token.

An attacker who steals the code doesn't have the verifier, and can't work it out from the challenge. RFC 7636 also defines a plain method that sends the verifier unhashed. It's only for clients that can't compute SHA-256, and new implementations shouldn't use it.

PKCE started as a fix for public clients, but current guidance applies it everywhere. The OAuth 2.0 security best current practice (RFC 9700) recommends it for all clients, and the OAuth 2.1 draft requires it for the authorization code grant. The MCP authorization specification says MCP clients must implement PKCE and use S256 when they can, and must refuse to continue if the authorization server doesn't advertise PKCE support in its metadata.

Vibely uses PKCE wherever it runs or starts an OAuth flow. The Vibely MCP server's authorization server advertises S256 as its only code challenge method, rejects any other method, and checks the verifier against the stored challenge before it issues a token. When the Vibely agent connects to a remote MCP server you add as a custom connector, Vibely generates its own PKCE pair. Workspace sign-in through OIDC SSO uses the same pattern, with code_challenge_method=S256.