OAuth 2.0 and PKCE
Prerequisites
Before reading this article, you need to study:
In the previous OAuth 2.0 and OIDC articles, we explained the authorization code flow. There is a key step:
The ExampleNote server exchanges the authorization code +
client_secretfor an Access Token.
This process looks good, but it has an important assumption: the client can keep the client_secret safe.
This is true for server-side web apps, because the client_secret is stored on the server and users or hackers can't access it.
But for mobile apps (Android, iOS), SPA (single-page web apps with only frontend, no backend), desktop apps, and so on, this is not true.
For example, if you build an Android app and want to support Google Login, following standard OAuth 2.0, you need to put the client_secret in your code.
But an Android APK can be decompiled, and anyone can extract the client_secret from your app.
This brings us to a key concept in OAuth 2.0: Client Types. There are two main types:
Confidential Client: A client that can keep the client_secret safe.
A typical example is a server-side web app, where the client_secret is stored only on the server, so neither users nor hackers can access it.
Public Client: A client that cannot keep the client_secret safe. This includes mobile apps, SPA apps, and desktop apps.
The Trouble of Public Clients
Public clients have two main problems:
Problem 1: Using client_secret Will Leak
If you hard-code the client_secret in an Android app, after APK is decompiled, hackers can get the key and impersonate your app.
Even if you use code obfuscation or reinforcement, it only makes cracking a bit harder. Putting the client_secret inside the app is always a big security risk and should be avoided.
Problem 2: Not Using client_secret Is Also Unsafe
If you don't use client_secret and only use the authorization code to get the token, you risk an authorization code interception attack: Hackers can catch the authorization code and use it to get the Access Token, gaining access to user resources.
So, using a static key will leak, and not using it is unsafe. What should we do? There is a special secure solution for public clients: PKCE (Proof Key for Code Exchange).
Here is the sequence diagram:
Below is the complete PKCE authorization code flow: