Here in this blog, we are going to discuss PKCE (Proof Key for Code Exchange) — an extension to the OAuth 2.0 Authorization Code flow for security purposes. If you are developing a Single Page Application (SPA) and concerned about token leakage or evil code injection, PKCE is something you should know about and use.
What is PKCE?
PKCE (pronounced “pixy”) is sort of an extra layer of security for your OAuth flow. It was primarily added to protect public clients such as SPAs or mobile applications, where you can’t securely keep secrets
So, what exactly does PKCE do?
It ensures that only the app that initiated the OAuth flow can complete it. Even if someone attempts to steal your authorization code, they can’t do anything with it unless they also possess a magic secret you created beforehand (called the code_verifier).
In short: PKCE = Proof that you’re the same app that asked for the login.
Why Do We Need PKCE?
SPAs are exposed to a number of attacks without PKCE:
- Authorization Code Injection: An attacker could inject false authorization codes into your app.
- Token Interception: Attackers have the ability to snatch your tokens on redirect.
- Code Reuse: Even when an old authorization code is reused, PKCE ensures that it won’t be accepted again
PKCE is similar to Command”handshake” between your frontend and the auth server to ensure all is well.
How PKCE Works (Step-by-Step)
Let’s go through the flow in 4 simple steps, assuming you’re using something like Spotify login in your frontend.
1. Generate a Code Verifier & Code Challenge
First, your app creates two strings:
- code_verifier – a random, secure string.
- code_challenge – a hashed version of that verifier (usually with SHA256).
This is what you’ll use to prove your identity later.
2. Redirect the User to the Auth Server
You now redirect the user to Spotify’s OAuth URL as follows:
https://accounts.spotify.com/authorize?
response_type=code
&client_id=your_client_id
&redirect_uri=your_callback_url
&code_challenge=code_challenge_here
&code_challenge_method=S256
This opens up Spotify’s login screen.
3. Get the Authorization Code
Once the user is logged in, Spotify sends an authorization code to your redirect_uri. This is a short-term code your application can use to obtain tokens.
4. Use Code to Obtain Access Token (with code_verifier)
Now here’s the catch: You don’t merely send the code to Spotify. You send the original code_verifier you generated at the start.
Spotify verifies: “Hmm, is this code_verifier the same as the original code_challenge we received previously?”
Yes – you receive your access token.
No – Spotify rejects the request.
That’s the “Proof Key” part in action.
Real-World Example: How PKCE Works with Spotify
- First your app creates a random string called a code_verifier. This is like a secret handshake that only your app knows. For example: XyZ123!@#.
- Next, it takes that code_verifier and runs it through a hashing function (most likely SHA-256) to create a code_challenge. for the sake of example, let’s say it becomes something like: abc789hash.
- Next, the app sends the user to Spotify’s login screen and includes that code_challenge in the request.
- Once the user logs in successfully, Spotify will redirect them back to the app with a temporary authorization code.
🔒 The cool part? Even if someone tries to steal that “auth_code", they can’t do anything with it unless they also somehow have your original code_verifier. That’s what keeps your app safe
Conclusion
So, here’s the takeaway — PKCE is like a digital bouncer for your OAuth flow. It only lets the right app finish the login process, keeping everything clean and secure.
Finally, for more such updates and to read more about such topics, please follow our LinkedIn page, Frontend Competency.