What is PKCE in OAuth 2.0? ??

PKCE stands for Proof Key for Code Exchange. Have you ever had the thought of "Wonder what would happen if someone else took my authorization code and exchanged it for access & refresh tokens? Would it actually work?". Well here's where PKCE comes in place.

PKCE prevents authorization code interception attacks by adding an extra step when exchanging the authorization code for an access token. Let's get a quick refresh on the Authorization Code Flow in OAuth 2.0

1. User clicks on "Sign in with google" for example
2. User is redirected to google to sign in
3. Once sign in succeeds, google then hits the callback url attaching the authorization code
4. After that a backchannel request is sent from the applications backend server to google's servers exchanging the authorization code for access token, refresh token and user information.

This is a generic flow, In MVC applications sending over the authorization code along with the client secret is generally safe because backend servers can securely store client secrets.

However in mobile apps, frontend apps you can't securely store secrets because javascript can be easily manipulated. So allegedly if anyone has the authorization code he can send it over to google and get an access token (you wish ??) Here's where PKCE comes in place

How PKCE works

1) Before starting the OAuth flow, the client generates:

• Code Verifier: A 43 and 128 characters long high-entropy, random string
• Code Challenge: A transformed version of the code verifier (usually using SHA-256 and Base64 URL encoding)

2) The client sends the authorization request to the authorization server with:

• code_challenge: The hashed code verifier.
• code_challenge_method: Usually "S256".

Sending the hashed value and the method so we can convert & compare anything sent to us later with these values

3) Authorization Server Returns Authorization Code

If the user approves, the authorization server returns an authorization code.

4) The client sends another request to exchange the authorization code for an access token, but this time it includes:

• code_verifier: The original random string (not the hashed one).

5) Server Validates Code Verifier

The authorization server re-computes the hash from the code verifier and checks if it matches the code challenge from step 2.

• ? If they match → Access token is issued.
• ? If they don’t → Request is rejected.

This can safely prevent anyone with the authorization code only to retrieve an access token. He would need the code verifier which is generated by the frontend during the lifecycle of the authorization flow

So to sum up everything

1. The frontend generates the code_verifier and derives the code_challenge from it.
2. It stores the code_verifier temporarily (in memory).
3. It sends the code_challenge (hashed version) in the authorization request.
4. After the user authorizes, the frontend retrieves the stored code_verifier and sends it in the token exchange request.
5. The authorization server verifies the code challenge and issues an access token.

If you have a backend server it would be more recommended to generate the code verifier there and just send the code challenge from the frontend as anything hashed can't be returned to its original state.

Adjusting the above if u have a backend server

1?? Frontend requests authentication:

• The backend generates the code_verifier and derives the code_challenge.
• The backend stores the code_verifier (in a session or database).
• The backend sends only the code_challenge to the frontend.

2?? Frontend redirects user to the authorization server:

• Sends the code_challenge (hashed version) in the authorization request.
• The user authenticates and the authorization server returns an authorization code.

3?? Frontend sends the authorization code to the backend:

• After user authentication, the frontend sends the authorization code to the backend.
• The frontend never handles the code verifier.

4?? Backend exchanges the code for an access token:

• The backend retrieves the stored code_verifier.
• It sends the authorization code + code_verifier to the authorization server.
• The authorization server verifies the code_challenge and issues an access token.

5?? Backend sends access token to frontend (if needed):

• If the frontend needs to make API calls, the backend can issue a session token or an HTTP-only cookie.
• The frontend never directly handles the OAuth access token, reducing security risks.

Hopefully you got something out of this little article! thanks and till the next one!