Exploiting OAuth 2.0 Protocol in Mobile Applications

November 30, 2016
Info notes


During Black Hat Europe 2016 a group of three researchers from the Chinese University of Hong Kong presented their research findings on the security of the OAuth 2.0[1] protocol in mobile applications. Known Identity Providers (IdPs), e.g. Facebook and Google, have adopted OAuth 2.0 for selectively granting access to user information/data to third-party applications. The researchers have identified that a large number of mobile applications use an insecure mobile variant of OAuth 2.0. Exploiting the identified security flaws of OAuth 2.0 implementations, allows attackers to remotely sign into a victim's mobile third-party application account without stealing the victim's credentials and without the victim being aware of the attack.

This note provides an overview of OAuth 2.0, its insecure implementations for mobile applications and the attack that leverages them. It also describes the causes of the attack, and provides recommendations on how to prevent/mitigate the attack.

OAuth 2.0, Insecure Implementations and Exploitation

OAuth 2.0 Overview

OAuth 2.0 is an authorisation protocol. When users log into third-party Web services using OAuth 2.0, they access their accounts by verifying their identity through their existing accounts on popular Web services such as Google, Facebook etc. In that way, they don't need to provide additional credentials to third-party services.

OAuth 2.0 in Mobile Applications

As the research describes, when a third-party mobile application uses OAuth 2.0, there are four parties involved:

  1. The client-side of the third-party (relying-party) mobile application
  2. The back-end server of the third-party (relying-party) mobile application
  3. The client-side of the IdP mobile application
  4. The back-end server of the IdP mobile application

Essentially, when a user attempts to log into a third party mobile application via OAuth 2.0, the IdP backend server issues an access token together with user information, e.g. user ID or e-mail address, to the third-party back-end server, which is sent through the client-side of the IdP and the client-side of the third-party mobile application respectively. Then, the third-party server debugs that access token and requests authorisation information from the IdP server directly. If the authorisation information received is correct, the third-party server can retrieve the user data associated with the access token and use them to identify and log-in the user.

The Flaws and Exploitation

The research underscores that many IDPs have adapted OAuth 2.0 protocol to support third-party mobile applications for their platforms. However due to the different needs of mobile applications in regards to OAuth 2.0 -in comparison to third-party websites that use OAuth 2.0, the original OAuth 2.0 protocol becomes under-specified. Certain security requirements and protocol details regarding the interaction between the third-party back-end server and its client-side counterpart or between the third-party client-side and the IdP client-side are not covered or well-defined. As a result, IDPs have developed different extensions of OAuth 2.0 APIs to support third-party mobile apps. These APIs are not always well-documented or well-understood by third-party developers.

Consequently there exist different OAuth 2.0 implementations for mobile applications. Some mobile developers  of the back-end server of third-party mobile applications have made different mistakes in their implementations though, with resultant security implications. According to the researchers, in various instances third-party back-end servers perform poor verification of the data they receive from their client-side counterparts and by extension the client-side of the IdP. They log-in users based on incomplete identity proof, e.g. based only on the user ID and not the access token it is bound to, relying on the assumption that data provided by their client-side counterpart is to be trusted. In the Web-site version of OAuth 2.0 this does not happen since third-party applications make the assumption that whatever data they receive from the browser is not be trusted until it is validated.

Consequently, as the researchers revealed, an attacker can exploit a third-party app that uses an insecure OAuth 2.0 implementation to access another user's account. First the attacker logs into their own account using their credentials, then having established a proxy that monitors the inbound and outbound traffic of their own device, they perform a man-in-the-middle attack by intercepting OAuth 2.0 messages received from the client-side of the IdP, and then they replace their user ID, e.g. username or e-mail address, with that of the victim's, which can be publicly found, before it is sent to the third-party client-side application and eventually to the back-end server. Since the third-party back-end server does not properly validate the user's identity, the attacker can sign-in as the victim.

Research Remarks/Results

The attack is mobile OS agnostic and affects users that have previously used OAuth 2.0 at least once to sign into a "vulnerable" third-party application. Leveraging such a flaw in the mobile OAuth 2.0 implementation, attackers can have full access to the victim's account and essentially to sensitive and private user information hosted by the third-party back-end server. Consequently, in some cases attackers can even perform actions on behalf of the victim. According to the researchers' empirical results, out of the 182 applications they tested, 41,2% (75) were found to be vulnerable to the attack, with the majority (58) of the vulnerable applications using an OAuth 2.0-based authentication service provided by a Chinese IdP called Sina. Vulnerable mobile applications that use an OAuth 2.0-based authentication service by Facebook or Google were fewer (9 and 8 respectively) but the latter two IdPs have much larger user bases.   

Issues Surrounding OAuth 2.0 in Mobile Devices

There are some serious issues surrounding the use of OAuth 2.0 by mobile applications:

  • In the meantime of the ongoing standardization[2] of OAuth 2.0 for mobile applications, various IdPs have developed their adaptations of OAuth 2.0 protocol to support mobile applications for their platforms, which leads to fragmentation. Therefore there is not a single, well-defined and extensively documented implementation of OAuth 2.0 for mobile applications, rather than different interpretations of the protocol, which lead to security issues.
  • IdPs do not extensively document their own OAuth 2.0 APIs for mobile applications or provide specific usage guidelines, thus they are not well understood by third-party mobile app developers, especially regarding their security requirements and assumptions. Consequently, as shown by the researchers, this leads to pitfalls and insecure implementations by the third-party developers.
  • Third-party application developers put a lot of trust in the information the back-end server receives from the client-side of the mobile application and by extension from the client-side of the IdP. Thus, they often do not properly validate received data. They make the assumption that whatever the third-party back-end server receives from its client-side counterpart is to be trusted. Since the client-side of the third party application may rely on potentially tampered data received from the client-side of the IdP mobile application, this is an incorrect assumption.


Based on the above issues related to OAuth 2.0 for mobile applications, several recommendations can be made:

For Internet Standards Developers

OAuth 2.0 for Web-sites has been widely adopted by IdPs and has been documented in detail. In contrast to that, it is evident that OAuth 2.0 for mobile applications is not at the same level of maturity, which strongly indicates the need for reassessing the protocol for mobile applications. OAuth 2.0 for mobile applications needs to be published under one official standard through an RFC. A complete and detailed documentation is needed to address all the security and operational nuances introduced by mobile platforms as compared with the Web-site version of OAuth 2.0. Through a universal standard, all IdPs and third-party developers will be able to use a standard that has been previously extensively tested. A clear and extensive documentation will help both IdPs and third-party developers in respectively adopting and implementing the protocol in both a uniform and more secure way.

For Identity Providers

IdPs need to make sure that their own OAuth 2.0 APIs are secure, and make appropriate updates if not. They also need make sure that third-party mobile application developers use their APIs properly. They must extensively document their OAuth 2.0 APIs for mobile platforms and provide specific and security-centric guidelines to third-party mobile application developers, describing in detail how they can correctly use their APIs. Having said that, IDPs should refrain from re-inventing the wheel by developing home-brewed extensions of OAuth 2.0-based APIs and consider using protocols, which try to rectify issues of past identity protocols, e.g. OpenID Connect, when possible. In any case IDPs need to make sure that their authentication service is well-documented, well-understood and correctly implemented by third-party developers regardless of the protocol they adopt.

For Third-party Mobile Developers

Third-party developers should be very cautious when incorporating OAuth 2.0 in their mobile applications. They should consult IdPs for correctly implementing the protocol and not draw deficient security assumptions relying on incomplete documentation and guidelines provided by IdPs, since this has proven to lead to insecure implementations.   


[1] RFC 6749 defines OAuth 2.0 as follows: "The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf".

[2] There is a draft IETF document called "OAuth 2.0 for Native Apps", which is still under development and focuses on OAuth 2.0 authorization requests from native apps made through external user-agents, primarily the user's browser.

* The Info Note has been updated. We would like to thank Mike Schwartz for his feedback.

About "Info Notes" from ENISA

With the "Info Notes" series ENISA aims to give interested readers some background information and recommendations about NIS related topics. The background information and recommendations derived from past experiences and common sense, and should be taken as starting points for discussions on possible courses of action by relevant stakeholders. Feel free to get in touch with ENISA to discuss or inquire more about the "Info Notes" series (cert-relations@enisa.europa.eu).

We use cookies on our website to support technical features that enhance your user experience.
We also use analytics. To opt-out from analytics, click for more information.

I've read it More information