Search code examples
securityoauth-2.0oauthtokenpkce

Understanding benefits of PKCE vs. Authorization Code Grant

I am new to the OAuth world and I am trying to understand the benefits of using PKCE over traditional Authorization code grant. (Many of my assumptions could be wrong, so I would thank for your corrections.)

I am a mobile app developer and according to OAuth documentation, client secrets can't be hardcoded in public clients' app code. The reason to avoid hardcoding the client secret is that a hacker could decompile my app and get my client secret.

The hacker with my client secret and my redirect_url, could develop a fake application. If a final user (User1) downloads the real application and the hacker's application (both), the fake application could listen to the real application callback and get the authorization code from it. With the authorization code (from the callback) and the client secret (stolen by decompiling my app), the hacker could get the authorization token and the refresh token and be able to get for example User1's data.

If other users download the real and the fake application, their data would also be in danger. Am I right? Would the hacker need both or could he/she do an attack only with the authorization code? Does the fifth step of the image require the client secret and authorization code?

The attack is called interception attack.

Enter image description here

To solve the the problem of hardcoding client secrets in the public client app and make it impossible for hackers to get the client secret and steal tokens, PKCE was invented. With PKCE, the client app code doesn't need to have the client secret hardcoded as PKCE doesn't need that information to get the tokens of the final users.

The PKCE flow creates a random string, transforms it to a SHA-256 hash value and to Base64. In the second point of the image, that encoded string is sent to the authentication server with the client id. Then the authorization code is sent in the callback and if any malicious app intercepts the code, it wouldn't be able to get the tokens as the fifth point of the image needs the original random string that was created by the legitimate app.

That is great, but if the client secret isn't needed any more to get the tokens to access User1 data, how can I avoid a hacker developing a fake app which uses PKCE flow with my client id and getting the tokens of the users who think that app is the legitimate one?

As the fifth step of the image doesn't need the client secret any more to get the tokens, anyone could develop fake apps using my public client id, and if any user downloads the fake app and does the OAuth flow, the hacker could get its tokens and access that user's data!

Am I right?

Solution

  • if the client secret isn't need anymore to get the tokens to access User1 data, how can I avoid a hacker developing a fake App which use PKCE flow with my client id and getting the tokens of the users who think that app is the legitimate one?

    OAuth 2.0 or PKCE does not protect against "fake apps".

    The PKCE does protect against having a malicious app on the device to steal a token that is intended for another app. E.g. think of a Bank app, it is not good if another app on the device can get the token that the Bank app is using. That is the case illustrated in your picture and that PKCE mitigates against.

    As the 5th step of the image don't need anymore the client secret to get the tokens, anyone could develop fake apps using my public client id.

    A mobile app cannot protect a client secret, similarly to JavaScript Single Page Applications. Therefore these clients are Public Clients rather than Confidential Clients according to OAuth 2.0. Only Confidential Clients can protect a client secret in a secure way, only those should use client secrets. PKCE is a good technique for Public Clients but might be used for Confidential Clients as well.

    if any user downloads the fake app and do the oauth flow, the hacker could get it's tokens and access that users data!

    Contact Apple Store or Google Play store for "fake apps", or use e.g. Anti-malware applications. That is the mitigations against "fake apps". PKCE only mitigates the case when another app on the same device tries to steal the token that is issued for another app (e.g. a bank app).