PKCE (Proof Key for Code Exchange) is pronounced Pixie and it was introduced in RFC 7636 to make the Authorization Code flow more secure.

This extension prevents CSRF and authorization code injection attacks.

It was first made to protect the authorization code flow in mobile apps since mobile apps are inherently public clients (a user can reverse-engineer the application to find hard-coded secrets).

Basically, if an attacker is able get an authorization client of a victim, it can talk to the token endpoint on the authorization server and get an access token for the user account. For example, if the authorization code is returned to the mobile app via a URI scheme that talks to the app ( read here ), and multiple apps can register as handlers for the same scheme - then the malicious app by the attacker can register as a handler and get the authorization code.

So What Did They Change?

Basically, we want to have a way to validate that the client that requested the authorization code is the same one that uses that code to request an access token.

They suggest adding two parameters to the authorization request, code challenge and transformation method.

There’s a notion of code verifier and code challenge, let’s explain it:

code verifier is a secret created on the fly by the client - it should have high entropy, used only once and unguessable to an attacker.

code challenge is what you get when you run the transformation method on the code verifier.

Now the client sends the code challenge along with the transformation method to the authorization endpoint when requesting an authorization code, the authorization server should somehow keep these challenge and method related to the authorization code it issued (can be in-band inside of the authorization code or out-of-band in the authorization server’s memory, if it’s in-band - it must be encrypted so an attacker that receives the code wouldn’t be able to get the code challenge and transformation method).

And in order to get the access token, the client sends the code verifier along with the authorization code, the authorization server runs the transformation method on the code verifier and makes sure it matches the code challenge sent at the start.

Even if an attacker gets the authorization code, they cannot use it to obtain an access token since they don’t know the original value of the code verifier.

Transformation Methods

There are two transformation methods and you should really only use the first one if your client is capble of that.

1. S256 (SHA256 digest of the code verifier)
2. Plain (no modification of the code verifier)

In order to pass the digests and the code verifier itself over HTTP, they are encoded as Base64 whenever used.