PKCE
Also called PKCE, Proof Key for Code Exchange, RFC 7636
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.
Where it comes from
Someone else specified this. Solidus assembles it.
PKCE, "Proof Key for Code Exchange by OAuth Public Clients", is IETF RFC 7636, published September 2015 by the OAuth Working Group. Its authors, Nat Sakimura, John Bradley, and Naveen Agarwal (Google), wrote it specifically to close a real, exploited weakness in mobile and single-page-app OAuth flows. Solidus wrote none of it; the code is a straightforward implementation of the published RFC.
How to check this
Running in production today.
curl https://auth.solidus.network/.well-known/openid-configuration and read code_challenge_methods_supported. A live ["S256"] confirms PKCE is required, not optional, on Solidus's own authorization endpoint.