PKCE

PKCE (pronounced "pixy") plugs a specific hole in the OAuth 2.0 authorization code flow (see OAuth 2.0): on a mobile app or single-page web app, there's no client secret that can stay secret, anything shipped to a device can be extracted and read. Without a secret, an attacker who manages to intercept the redirect containing the authorization code, via a malicious app registered for the same custom URL scheme, for instance, can potentially exchange that code for a token themselves, at the token endpoint, before the legitimate app does.

PKCE closes that by making the app prove it's the same app that started the flow, without needing a pre-shared secret. At the start, the app generates a random string (the code verifier), hashes it (the code challenge), and sends only the hash when it kicks off login. When it later exchanges the authorization code for a token, it also sends the original, un-hashed verifier. The authorization server checks that hashing the verifier now produces the challenge it was sent earlier, something only the app that started the flow could have, since only it ever held the original verifier. An attacker who intercepts just the authorization code midway through has nothing that hashes to match.

Where it comes from

PKCE is RFC 7636, published by the IETF OAuth Working Group in September 2015, authored by Nat Sakimura, John Bradley, and Naveen Agarwal. It's since become recommended practice for essentially every OAuth client, not just the mobile and single-page apps it was originally written for, current OAuth security guidance treats it as a baseline, not a special case. Solidus implements it as published.

Solidus today

auth.solidus.network's /authorize and /token endpoints require PKCE (S256 code challenge method) for the authorization code grant. Solidus also acts as a PKCE client in several places: verify's enterprise SSO module, wallet's login flow, and verify-capture's console all generate and send a code verifier when authenticating against a third-party identity provider. All of it is testnet, unaudited.

See also

OAuth 2.0 is the flow PKCE hardens. OIDC inherits the same requirement. DPoP solves a related but distinct problem, binding the resulting token to a key, rather than protecting the code exchange itself.