Auth and identity · Protocol

PKCE

An extra check in the OAuth sign-in flow that stops an intercepted authorisation code being used by anyone except the app that started the sign-in. Mobile and single-page apps depend on it.

Tokens and sessions · updated

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.

More in Auth and identity

Tokens and sessions

All 17 Auth and identity terms

Crafted in the dark. Shipped to the world.

Tell us what you are building. You get a private project space with a proposal and a line-by-line quote within a day.