PKCE Explained: Securing Your App’s Login Flow Without Exposing User Secrets

I recently spent some time learning about PKCE — short for Proof Key for Code Exchange. If you’ve ever used an iOS app, you’ve probably noticed this flow: you tap “login,” a browser window opens, you enter your credentials there, and then you’re redirected back to the app — already logged in. PKCE is a secure way to handle exactly this process.

But before diving into PKCE, a natural question comes up: why involve a browser at all? Why can’t the app just handle login directly?

Technically, it can. An app could simply send your username and password to a server via API calls. But here’s the problem — if the app is even slightly compromised, your password could be exposed to an attacker. To avoid that risk, it’s better to let the server handle credentials entirely. The app never touches the password; instead, it receives a token from the server and uses that token for future API requests. This shifts the responsibility of security to the server and lets app developers sleep a little better at night.

So far, so good. But then why do we need PKCE?

Traditionally, the flow worked like this: the app sends the user to log in via a browser. After a successful login, the browser redirects back to the app with something called an authorization code. The app then sends this code to the server and says, “Here’s the code — give me the access token.”

Sounds simple. But there’s a catch.

The problem lies in that redirection step. Imagine a malicious app quietly sitting on the user’s device. When the authorization code is sent back via a URL (like myapp://callback), that malicious app could intercept it—essentially snatching the code mid-transfer. Since the code travels through the browser in a relatively exposed way, this isn’t an impossible scenario.

Now here’s the scary part: if the attacker gets that authorization code and sends it to the server, the server has no way of knowing whether it’s the legitimate app or not. It might just hand over the access token. And just like that — the user’s account is compromised.

This is exactly the problem PKCE was designed to solve.

At its core, PKCE introduces a kind of “secret password” that only the original app knows. The process works in three main steps:

1. Creating a secret (Code Verifier) Right before starting the login process, the app generates a long, random string — this is called the code verifier. Then it transforms this string using a hashing method into something unreadable, known as the code challenge.

2. Sending the challenge to the server When the app opens the browser for login, it sends this code challenge to the server. The server stores it. Importantly, the original secret — the code verifier — never leaves the app and stays in its memory.

3. Proving identity with the original secret After login, when the browser redirects back with the authorization code, the app makes another request to the server. This time, it sends both the authorization code and the original code verifier.

Now comes the server’s role.

The server takes the received code verifier and applies the same hashing method to it. Then it compares the result with the previously stored code challenge. If they match, the server knows for sure: this is the same app that initiated the login process.

Even if an attacker manages to steal the authorization code, they won’t have the original code verifier. So when they try to exchange the code for a token, the server will reject them.

In other words, just grabbing the authorization code isn’t enough anymore. Without the verifier, the attacker can’t impersonate the real app or obtain the access token.

So, in simple terms, PKCE is a verification mechanism that ensures no one can hijack your “login ticket” midway and use it. It keeps user passwords away from the app and protects against interception attacks during the authentication flow — making the entire process significantly more secure.