How it works
Before redirecting to the provider, the app makes a random secret (the code verifier) and sends only its SHA-256 hash (the code challenge). When it later swaps the authorisation code for tokens, it must present the original verifier, and the provider checks that it hashes to the challenge. A malicious app or script that grabs the code on its way back cannot use it, because the verifier never left the real app.
PKCE (pronounced 'pixy', defined in RFC 7636) was created for apps that cannot keep a client secret, since anything shipped inside a mobile app or a JavaScript bundle can be extracted. It replaced the old implicit flow for single-page apps, current security guidance recommends it for server-side apps too, and OAuth 2.1 makes it mandatory. Good OAuth libraries and auth SDKs handle it automatically.
Related terms
More in Auth and identity
Tokens and sessions