1

I understand the Oauth code flow which involves the mobile app, app server, auth server, resource server. The app server is registered with auth server using the clientidand secret. The idea being that mobile app calls an endpoint of the app server which triggers the code flow eventually resulting in callback from the auth server to the app server with the auth code. The app server presents the secret and code to auth server to get the access token.

The other legacy option where there is no clientid and secret is the implicit flow wherein the mobile app receives the redirect url with the auth code (assuming redirect url destination is a SPA) which will invoke auth server endpoint to get the access token.

This is insecure because anyone can steal the access code from the url.

The solution to this for clients like mobile app is to use pkce. A random number hash is sent in the initial request which is verified later on when the auth code is passed to retrieve the access token.

This prevents the compromise of the access code from the url if an attacker is snooping because without initial hash the auth code is useless.

However how can the situation where the mobile phone is hacked and the secret and auth code is recorded by an attacker be handled to prevent misuse?

variable
  • 8,262
  • 9
  • 95
  • 215

2 Answers2

2

These are the standard options:

  • PKCE uses a different code_verifier and code_challenge for every login attempt. If an authorization code is somehow captured from the system browser by an attacker it cannot be exhanged for tokens. No client secret is used, since a mobile app is a public client.

  • Use HTTPS redirect URIs (based on mobile deep links) so that if an attacker steals your client_id and redirect_uri they cannot receive the response containing the authorization code and will not be able to get tokens.

See this previous answer of mine for some further details, though claimed HTTPS schemes are tricky to implement.

Of course if an attacker has full control over a device, including authentication factors such as autofilled passwords, there may still be attack vectors

Gary Archer
  • 22,534
  • 2
  • 12
  • 24
2

However how can the situation where the mobile phone is hacked and the secret and auth code is recorded by an attacker be handled to prevent misuse?

This is out of scope for OAuth 2.0 & related specifications. This issue is similar to storing encryption details in a server, but still, the server can be attacked by gaining physical access. It's a different attack vector altogether. It is user's duty to make sure their devices are safe from other vulnerabilities.

However, PKCE provides an extra security layer for public clients' usage of OAuth flow. It prevents attacks based on redirect (authorization code stealing), by establishing secondary validation at the authorization server.

In general, read through OAuth 2.0 Threat Model and Security Considerations & OAuth 2.0 for Native Apps for best practice suggestions.

Kavindu Dodanduwa
  • 12,193
  • 3
  • 33
  • 46