Pitfalls of using OAuth for mobile Applications

Question

OAuth seems to be getting a lot of traction at the moment as an authorization solution for web applications and mobile applications.

I'm interested in understanding what the pitfalls of using OAuth are in those two scenarios (as a web application providing OAuth access to my users information to other websites, and also providing access to mobile (eg, Android, iOS) applications.

Answer 1

Well the first consideration is that SSL/TLS is absolutely necessary to implement correctly.

One must also consider 2-legged or 3-legged authn mechanisms. While most are going to recommend the more complex (and safe) 3-legged approach, it is possible that 2-legged would have advantages when done right for certain apps.

There have been some timing attack discoveries on OAuth done by rootlabs. There are also risks from XSS/CSRF and ClickJacking (and other attacks against the authn), just like in any web application.

ArsTechnica ran two articles on the OAuth security architecture, one linked from Bruce Schneier.

Answer 2

I don't have enough points to make a comment, so I added this as an answer. OAuth is firstly an authorization protocol and not mainly an authentication. Even though authentication is embedded within the protocol, it is not the main purpose.

Answer 3

The biggest problem with OAuth 1.0a in mobile and desktop applications is that the Consumer/Application key and Consumer/Application secret, which are used to sign the requests, can be extracted and exposed publicly.

For example, if you're provider of data and you create and give a consumer key to another third party web application that wants to access your users data, the key and the secret will always be hidden well in the third party web server. Nobody is supposed to have access to them (except some sysadmin or developer). But this key is not exposed publicly to the world.

However, in the case of mobile or desktop application, the end-users have to download this applications to their phone/computer. Therefore any hacker can download the application and extract the key/secret pair from the program. Consequently, he can build a malicious application that is pretending to be the original consumer application.

This is by far the most serious problem of OAuth that I know of, at least in 1.0a version of the protocol. The problem is not so serious, because end-users will still have to approve access to the malicious application and it's up to them to see that it has different name and that it may be suspicious about the ACCESS that it wants. However, when you as a provider expect to have mobile consumers, you should never trust them to be the ones, that they say they are.

As far as the examples above given from ATDRE, I don't think you have to worry that much, because these articles present some hypothetical scenarios and do not say anything concrete about OAuth flaws. OAuth 1.0a is perfectly secure as a protocol if it's done over SSL. The attacks for which they talk about are just common examples of web hacking, that has nothing to do with OAuth.

For example, if someone steal the end-user's cookie, of course he can login and approve requests on behalf of the user... but this is not OAuth problem. Or the timing example, which is an example of a particular library implementation of the protocol, not with the protocol itself...

I'm sorry that I cannot tell you details about OAuth 2.0, because I haven't implemented that version yet, however I can tell you that 1.0a version of the protocol is good from security standpoint...