OAuth Code Flow
In Figure 1, we briefly introduce how the OAuth flow works on mobile apps and show show the reason why we do need PKCE.
In our example the user has two apps installed on the mobile phone: an Honest App and an Evil App. We assume that the Evil App is able to register the same handler as the Honest App and thus intercept messages sent to the Honest App. If you are more interested in this issue, you can find more information here .
|Figure 1: An example of the "authorization code interception" attack on mobile devices.|
- The Honest App could use a Web View browser. However, the current specification clearly advice to use the operating system's default browser and avoid the usage of Web Views . In addition, Google does not allow the usage of Web View browser since August 2016 .
- Optionally, in step 5 the App can authenticate on the Authorization Server via client_id, client_secret. Since, Apps are public clients they do not have any protection mechanisms regarding the storage of this information. Thus, an attacker can easy get this information and add it to the Evil App.
Proof Key for Code Exchange - PKCE (RFC 7636)
|Figure 2: PKCE - RFC 7636|
- The Honest App generates a random string called code_verifier
- The Honest App computes the code_challenge=SHA-256(code_verifier)
- The Honest App specifies the challenge_method=SHA256
Step 2: The Authorization Server receives the Auth Request and binds the code to the received code_challenge and challenge_method.
- Later in Step 5, the Authorzation Server expects to receive the code_verifier. By comparing the SHA-256(code_verifier) value with the recieved code_challenge, the Authorization Server verifies that the sender of the Auth Request ist the same as the sender of the code.
PKCE Bypass via App Impersonation
|Figure 3: Bypassing PKCE via the App Impersonation attack|
OAuth 2.0 for Native Apps
Christian Mainka (@CheariX)