If you're using OAuth 2.0 to secure your API — that's great.

But if you're NOT using PKCE with it, your API might still be vulnerable.

Most developers implement OAuth 2.0 and think they're done.

The truth? OAuth alone is open to interception attacks .

What's the problem?

When a user logs in via OAuth 2.0, an authorization code is

returned in the URL.

A malicious app on the same device can intercept that code.

And exchange it for an access token.

Without ever knowing the user's password.

How PKCE fixes this

PKCE (Proof Key for Code Exchange) adds two things:

A code_verifier — a random secret string

A code_challenge — SHA-256 hash of that verifier

The verifier is sent with the token request.

The server checks it matches the original challenge.

If someone intercepts the code — they can't use it.

Because they don't have the verifier.

What I cover in my video

I made a 9-minute tutorial breaking down:

✅ How OAuth 2.0 authorization flow works

✅ Where the vulnerability exists

✅ How PKCE plugs…