• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1615
  • Last Modified:

OAuth 1.1 vs. OAuth 2.0

From my reading I blieve that the following is the case

OAuth 1.1:    Simple, not very secure, and popular in the Mobile community

OAuth 2.0:   More complex, more secure, not particularly popular

Open in new window

Which one is more popular, which one has more uses in general

Which one has more mobile users

Anthony Lucia
Anthony Lucia
2 Solutions
Olaf DoschkeSoftware DeveloperCommented:
Au contraire.

See http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/

Also you mean OAuth 2.0 vs 1.0a, there is no version 1.1 AFAIK. I have implemented the client side OAuth1.0a and 2.0 logic and haven't looked at how the protocol(s) evolved since 2010. But as far as I see there is not much news.

Most important, perhaps: As a client software developer you don't decide which OAuth version to use, as that depends on what OAuth version is implemented by the service you want to use via OAuth authentication. Very few services allow you to choose between both versions. Google offers both (or did back in 2010)

The weak point of the OAuth 2.0 protocol is the secure storage of long life refresh tokens by clients. With them access tokens can be requested without repeatedly going through the authentication process and they are not bound to a certain client with it's own client secret and API key, so getting at a refresh token any other client software can use it. That's a consequence of dropping a more complex signing of requests OAuth 1.0a asks of clients.

In my opinion the signing process defined in OAuth 1.0a is making it more secure, than the SSL encryption secures tokens sent for OAuth 2.0 requests. Every OAuth1.0a request must be signed and the signature ensures not only the client knows the access token needed, but also, that it's the client making the request.

No matter what OAuth version you use, when starting the authorization process the user is asked to sign in, there is a weak point at that moment a client may redirect the user to a phishing site asking for the "normal" user/password credentials of a service (may it be Twitter, Facebook or whatever other login). So malicious clients may not try to authenticate with a service, but instead direct the user to a phishing site asking for their credentials, which is even more valuable than getting an access token.

The protocol should fail at that time, if the user isn't already having an active session, because that assures the user previously logged in with the original login. That would be my suggestion to make the authentication process more secure.

In short: You normally don't have the choice what OAuth version to use. Don't reinvent the wheel and take some OAuth library. I'm not a Java developer, but others may point you to an OAuth library you can use for your software.

Bye, Olaf.
Although I can't comment on the popularity of "non-Oauth 2.0", the security standard is moving towards Oauth 2.0 if not already for many of the big online brands like Facebook, Google Twitter and Microsoft.

For example, Google wrote in a blog in April they will start enforcing extra security measures for non-Oauth 2.0 applications: "The standard Internet protocols we support all work with OAuth 2.0, as do most of our APIs. We leverage the work done by the IETF on OAuth 2.0 integration with IMAP, SMTP, POP, XMPP, CalDAV, and CardDAV."

Some other helpful links:

OWASP Authentication Cheat Sheet: https://www.owasp.org/index.php/Authentication_Cheat_Sheet#OAuth 

Making auth easier: OAuth 2.0 for Google APIs: Another http://googledevelopers.blogspot.ch/2011/03/making-auth-easier-oauth-20-for-google.html

Featured Post

When ransomware hits your clients, what do you do?

MSPs: Endpoint security isn’t enough to prevent ransomware.
As the impact and severity of crypto ransomware attacks has grown, Webroot has fought back, not just by building a next-gen endpoint solution capable of preventing ransomware attacks but also by being a thought leader.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now