Q
Problem solve Get help with specific problems with your technologies, process and projects.

Insecure OAuth implementations: How are mobile app users at risk?

Mobile apps using insecure OAuth could lead to over one billion user accounts being attacked. Expert Michael Cobb explains how developers can implement OAuth securely.

Researchers developed a possible attack on mobile apps with insecure OAuth implementations that may put more than...

one billion user accounts, whether Android or iOS, at risk of stolen data. What is the OAuth vulnerability? What can application developers do to ensure secure OAuth implementations?

OAuth 2.0 is an open standard for token-based authorization that allows a user's account information to be accessed by third-party services, without sharing or exposing the user's credentials. It's widely used to facilitate single sign-on (SSO), so users can sign in to third-party websites and apps by using an ID provider (IdP), such as Google, Facebook, Sina Weibo or Twitter.

However, OAuth was originally designed to support authorization for third-party websites, not for authentication or mobile apps. Attempts to adapt OAuth to support mobile app authentication have inevitably created implementation vulnerabilities.

Researchers at the Chinese University of Hong Kong have found vulnerable OAuth implementations in 41% of the 600 most popular Android apps in the U.S. and China. They demonstrated a remote exploit over the Android platform that enables an attacker to sign in to a victim's mobile app account via OAuth 2.0, without any need to phish or interact with the victim. This means that more than one billion mobile app accounts may be at risk of data theft.

As this exploit is platform-agnostic, the fault is in implementation, and is not a flaw in the OAuth 2.0 mechanism. Any iOS or Android users of vulnerable mobile apps are at risk if they have used an OAuth 2.0-based SSO service with the app before.

The common error that all the vulnerable apps make is failing to validate information received during the SSO process, and relying solely on misplaced trust instead. Some apps do not verify the signature from the IdP, while others do not confirm that the user ID returned is bound to the OAuth token. Many apps and their back-end servers also blindly trust the authenticating information obtained from the client-side mobile app of the IdP or from each other.

This lack of validation means an attacker can log in to a vulnerable app using their own credentials, and then substitute their own user ID with that of the victim during the OAuth exchange. If the third-party back-end server doesn't verify the user identity information it receives from its client-side app, the attacker can successfully sign in to the app as the victim. In many cases, the attacker then has full access to the victim's information hosted by the third-party app's back-end server.

There are two reasons why this vulnerability affects so many mobile apps. Firstly, OAuth 2.0 is more of a framework than a defined protocol. It does not cover or define the interactions or the associated security requirements between the four parties required to support SSO for third-party mobile apps: the third-party client-side mobile app, the third-party back-end server, the client-side mobile app of the IdP and the back-end server of the IdP. This has led various IdPs to adapt or extend OAuth 2.0 to support SSO for third-party mobile apps to satisfy their specific platform and business logic. These adaptions tend not to be that well-documented. Combine this with a general lack of understanding of the security implications and differences for OAuth implementations on mobile platforms, and there are plenty of opportunities for poor coding and insecure practices to put users' data at risk.

Developers who use OAuth implementations should review their code and update it, if necessary, to perform additional checks, such as validating the signature attached to the authentication information sent by the IdP and checking the OAuth information to see if it's linked to the user ID.

Developers often copy and paste code from OAuth website examples into mobile apps and expect them to be secure. Most do not read the accompanying implementation notes and advice, so IdPs need to provide clearer implementation guidelines, along with working mobile app-specific examples of how to securely implement SSO using their flavor of OAuth. There should be a checklist to which developers can refer to ensure all the necessary safeguards have been implemented. Apps should be stress tested prior to launch to prove the security controls work as intended.

More IdPs need to follow Facebook's lead and issue private account identifiers instead of public identifiers, such as email addresses. This makes discovery of user identifiers harder, though not impossible. An even better approach would be issuing private user identifiers on a per-mobile-app basis.

Next Steps

Find out how the Pokémon GO app was granted a full-access OAuth token by Google

Learn about the benefits of applying single sign-on technology to mobile apps

Read how the Dirty COW vulnerability in the Linux kernel enables attacks on Android devices

This was last published in April 2017

Dig Deeper on Single-sign on (SSO) and federated identity

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What has your enterprise's experience been with OAuth security?
Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close