The best practice document from Internet Engineering Task Force (IETF) recommends the use of an external user agent (such as a browser) to complete the flow in authorization flow code grant. When a native app wants to access private information, it needs to first get an authorization code. The native app starts its authorization request via the browser, which completes Step 3 and 4 (as shown in Figure 1) to get an authorization code. The browser then passes the authorization code back to the native application via a mechanism facilitated by the client operating system. The native application then exchanges the authorization code for an access token. Figure 2 illustrates the communication between a native application and the browser.

Authorization Code Interception Attack

The authorization code grant flow is supported by both confidential and public clients. It is possible for an attacker to reverse engineer a mobile application to gain access to the client secret. In the case of single page applications (SPA), the client secret is available in the web code, openly accessibly in the browser. With a client secret and authorization code, a malicious application can effectively impersonate the original application for which the authorization code was issued. This is called an authorization code interception attack. The idea is to exchange that authorization code for “Access Token” and optionally “Refresh Tokens” from the token endpoint and gain access to a user’s account. Figure 3 illustrates the weakness in this authorization code flow sequence.