A Comprehensive Guide to OAuth

In the past few years, OAuth has become a highly influential protocol due to its quick and wide adoption in the industry. The protocol was started with the objective of fulfilling authorization needs for websites. Over the years, it has become more than just that.

The protocol has been significantly repurposed and re-targeted over the years especially now to the mobile platform apart from the web. While it has picked up pace and adoption, it has also become a target for hackers precisely for the same reason and also because most developers do not implement it the right way.

Let's try and delve deeper on this protocol and understand why this is both a boon and a bane.

What is OAuth?

OAuth is an open standard which was initially envisioned by the developers behind Twitter’s OpenID. Since then it has gained rapid adoption across many websites including Facebook, Google, LinkedIn and more. It is widely used in a variety of web and mobile applications especially to provide mechanisms for user authentication. This has, in fact, led many developers and API providers to believe that OAuth itself is an authentication protocol. Actually, OAuth is not an authentication protocol.

Most of this confusion is because OAuth is used inside of authentication protocols. What happens is developers see the OAuth components and interact with its flow and often most of them assume that simply using OAuth can result in user authentication. This is not just untrue but also very dangers for businesses and users.

Then what exactly is OAuth? 

A paper written by researchers of Carnegie Mellon University explains this very well.Originally, OAuth was designed to provide a secure authorization mechanism for websites. It defines a process for end-users to grant a third-party website the access to their private resources stored on a service provider. The third-party website is often referred to as the consumer, client, or relying party. Often the word relying party is used.

There are two versions of OAuth protocols, OAuth 1.0 and OAuth 2.0 They are both actively use by real-world websites. Ever since OAuth was successfully adopted by the industry, major companies have re-purposed OAuth for authentication as well.

That is, the protocol enables a user to prove his/her identity to a relying party, utilizing his/her existing session with the service provider. The web industry’s trend to obsolete other protocols and move toward OAuth is decisive – the new authentication mechanisms provided by the aforementioned companies are all OAuth-based.

Therefore, despite the fact that neither OAuth 1.0 nor OAuth 2.0 documentation is explicitly geared for authentication, OAuth is now a de-facto authentication and authorization protocol.

Authentication Vs Authorization

The OAuth website gives a simple metaphor to understand this - chocolate vs. fudge. Basically, the nature of both is different - chocolate is an ingredient, fudge is a confection. Chocolate can be used to make many different things, and it can even be used on its own. Fudge can be made out of many different things, and one of those things might be chocolate, but it takes more than one ingredient to make fudge happen and it might not even involve chocolate. As such, it's incorrect to say that chocolate equals fudge, and it's certainly overreaching to say that chocolate equals chocolate fudge.

Related Topic- Understanding OWASP Top 10 Mobile: Poor Authorization and Authentication

OAuth, in this metaphor, is chocolate. It's a versatile ingredient that is fundamental to a number of different things and can even be used on its own to great effect. Authentication is more like fudge. There are at least a few ingredients that must be brought together in the right way to make it work, and OAuth can be one of these ingredients (perhaps the main ingredient) but it doesn't have to be involved at all. You need a recipe that says what to combine and how to combine them, and there are a large number of different recipes that say how that can be accomplished.

OAuth for Mobile Applications

Just like their web counterparts, mobile applications also need authentication and authorization. After gaining popular adoption in the web space, it was inevitable that OAuth became the obvious choice in the mobile space too. According to a study, more than 24% of the 600 top Android applications taken from several Google Play categories use OAuth.

So, what's the big deal you ask?

Well, the usage of OAuth for mobile has some security concerns as this protocol was primarily designed for traditional web technology and not for mobile platforms. Hence, it becomes, even more, important to educate mobile application developers about this. It has been observed that despite it's wide usage, the OAuth protocol is quite complicated for average developers to comprehend and handle.

Here's an example of its complexity - the security property of the OAuth access token differs across OAuth 1.0 and OAuth 2.0. In OAuth 1.0, each access token is bound to and can only be used by the relying party the access token was issued to. However, an access token in OAuth 2.0 (which is also referred to as a “bearer token”) can be used by any party in possession of this token.

Must Read: 3 Basic Mobile Security Principles that Every App Developer Should Be Aware of

The diversity of mobile applications is the real cause of issues with OAuth in mobile platforms. Not only is the protocol defined in multiple specifications with two different use-cases, but also its mobile usage is poorly defined and underspecified. This is why developers are often forced to have their own interpretations, most of which is bad from a security point of view.

Understanding OAuth 1.0 and OAuth 2.0

Before OAuth was launched, there existed another popular protocol called OenID for third-party user authentication. OpenID had an issue - secure API access delegation. In simple words this means authorization and hence, OAuth was designed to mainly address this problem of authorization.

Here's a diagrammatic representation of the connection flow in the case of OAuth 1.0 and OAuth 2.0

OAuth 1.0 Connection Workflow

OAuth 1.0 had several notable limitations for its usage scenarios. However, instead of augmenting the existing protocol, the working group decided to alter the specification completely to create a different protocol – OAuth 2.0.

A major change introduced by OAuth 2.0 was the concept of bearer tokens. That is, a user’s access token was no longer bound to a relying party; any party in possession of this token could freely access the user’s protected resource.

Common Security Issues with OAuth

1. Access Tokens as a Proof of Authentication

Authentication usually occurs before the issuance of an access token. Often developers are tempted to consider the reception of an access token as a proof of authentication. However, just possessing an access token doesn't tell the client API anything by itself. For true authentication to occur the client should be able to get some information from the token, which doesn't happen in the case of OAuth. In the case of OAuth, the client is the authorized presenter of the token and the audience in fact is the protected resource.

2. Storing Relying Party Secrets Locally

A common issue is that developers fail to understand the purpose of relying upon party secret and end up storing it locally inside the client application. Researchers believe that the terminology of OAuth confuses developers significantly – the relying party secret is referred to as the “consumer secret” by OAuth 1.0 and “client secret” by OAuth 2.0, where the terms consumer and client are used by each specification to describe the relying party. These names are misleading for developers who have never studied the specifications, which is a majority of them. These names are extremely misleading for developers who have never studied the specifications.

Here's a real life example:

The research paper written by Eric Chen, et al. highlights a real-world example of Pinterest and Quora.

Both Pinterest and Quora used Twitter as a service provider for authentication, and both of them bundled their relying party secrets with their mobile applications. To make the matter worse, after obtaining their secrets using simple reverse engineering, we discovered that the same secrets were used for the Pinterest and the Quora web applications. Since Twitter mainly used OAuth 1.0, this gave an adversary the ability to generate arbitrary OAuth request tokens for Quora and Pinterest. Using these tokens, we (acting as the attacker) could direct users (both web and mobile users) to a legitimate Twitter page with the dialogue box. Once the user clicks authorize, Twitter’s access token will be sent to the attacker, giving him/her full access to the user’s account. 

3. Injection of Access Tokens

Here's another very dangerous security threat as far as OAuth implementation is concerned. This is where a client accepts access tokens from sources other than the return call from the token endpoint. This can occur for a client that uses the implicit flow (where the token is passed directly as a parameter in the URL hash) and don't properly use the OAuth state parameter.

This is problematic because it opens up a place for access tokens to potentially be injected into an application by an outside party (and potentially leak outside of the application). If the client application does not validate the access token through some mechanism, it has no way of differentiating between a valid token and an attack token.

This is a problem because it opens up a place for access tokens to potentially be injected into an application by an outside party (and potentially leak outside of the application). If the client application does not validate the access token through some mechanism, it has no way of differentiating between a valid token and an attack token.

So, how do you solve this? This can be solved by using the authorization code flow and only accepting tokens directly from the authorization server's token endpoint, and by using a state value that is unguessable by an attacker.

4. Issues With Mobile Browser and WebView

Since the OAuth specification does not specify how to perform user-agent redirection for mobile applications, it may seem natural to use a mobile browser or an embedded browser (i.e., WebView) to perform web-based OAuth redirections on mobile devices.

Again, an issue that is highlighted in the research paper by CMU is as under:

The WebView usage is very common for service providers that utilize a single protocol flow for both web and mobile relying parties. Many notable service providers that fall into this category, including Twitter, Microsoft LiveID, Flikr, and Renren.

Unlike Facebook and Google, these service providers do not facilitate OAuth flows for mobile relying party using their own mobile applications. Instead, they choose to use their websites to conduct all mobile OAuth transactions.

Many mobile developers natıvely believe that since the OAuth specification is specifically designed for web usages, one can securely apply it to mobile platforms by using the web-based flow inside a mobile web browser (or a WebView instance). This is a common misconception, as we have not found a single case in our study where a mobile browser or WebView is used securely for OAuth.

Conclusion

Everything is moving to social and mobile, integrations with Facebook and similar social websites. With the growing usage of smartphones, both businesses and users want quick access to services and systems. OAUth is a great way to achieve that but like we mentioned above, it is essential to implement this in the right way else it can end up being a pain for your business and users.