OAuth 2.0 101

Many luxury cars come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will only allow the car to be driven a short distance while blocking access to the trunk and the onboard cell phone. Regardless of the restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else. – The Official Guide to OAuth 1.0

That’s how the community-based specification guidelines explained OAuth way back in 2007. And while OAuth 2.0 is a completely new protocol, the same description still applies – OAuth remains a way for users to grant third-party access (and limited access) to their resources without sharing their passwords.

If you are on the Internet regularly, chances are you have come across a site that uses OAuth. After all, the world’s biggest websites, such as Facebook, Google, MySpace, Twitter, Photobcuket, Yahoo, Evernote and Vimeo, use this authentication standard. Read on to learn more about this standard, and why the next generation, OAuth 2.0, is still being used on a relatively experimental basis.

What Is OAuth 2.0?

First, you need to know what OAuth, as a protocol, does: It allows application programming interface authorization between two Web or desktop apps. As a result, websites are able to share protected resources with other websites and services.

For example, if you play Scramble with friends on your iPad, you could enter your Facebook credentials, allowing the game to look through your friends list to see which of them are playing the game – and invite others to join. Or you could connect with friends on Google+ based on who’s following you on Twitter. These type of applications are handy for users, but they involve giving one site or program access to information about you on another site.

OAuth 2.0 works much like the first incarnation of OAuth, but it is a totally new standard altogether. This means that it is not backward compatible with OAuth 1.0. Version 2.0 cleaned up many of the problems with the original OAuth and made improvements.

While basically retaining the architecture of the first version, 2.0 improved on:

• Authentication and signatures. OAuth 2.0 made it easier for somebody on the client side to implement the protocol.
• User experience and alternative ways to issue tokens
• Performance, especially with larger websites and services

A more comprehensive explanation on what is new with OAuth 2.0 is provided by Eran Hammer, who used to be part of the OAuth working group. You can access it here. However, note that Hammer left the working group in July of 2012, citing issues with security concerns when implementing the standard. As a result, although OAuth was supposed to be finalized by the end of 2010, it remains a proposed standard (at time of writing), although it is part of Facebook’s Graph API. Google and Microsoft are also experimenting with OAuth 2.0 support in their APIs.

The Benefits of Using OAuth 2.0

One of the best reasons to use OAuth is that it makes sharing so much easier. We’re already used to uploading photos to Instagram and having them post automatically to Twitter and Facebook. In fact, it’s this kind of ease of use and crossover that continues to make social media so appealing.

But that’s not all. For end users, OAuth means that you do not have to create another profile. For example, if you want to leave a comment on an article, you can use your Facebook or Twitter credentials to do so, instead of having to sign up for an account on a given website. This is great for sites that you aren’t usually active on, or that you may not trust. It can also benefit the sites by ensuring that users have an identity on Facebook, making comment spam less likely.

OAuth also means fewer passwords to remember. It’s a best practice to have different passwords for different website services. So instead of memorizing another password for Pinterest, you only have to use your Facebook password to access the service. Pinterest, by the way, won’t see your password.

You can also limit what resources are accessed via your OAuth. For example, when playing a game on Facebook, you can specify if you want the game to be posted on your wall on your behalf or not.

For the developer, OAuth 2.0 provides an already developed code for authentications, social interaction display and user profile display. This means fewer bugs for developers to contend with and a lower risk because the API has already been debugged, tested and proven. Lastly, you also benefit from having less data to stored on your own servers.

How OAuth 2.0 Came to Be

It is quite obvious that OAuth is a response to the call for secure computing and ease of use for different Web services. OAuth 2.0, on the other hand, arose from the need to make OAuth less complex. But the whole idea for both actually came from OpenID.

OpenID is a service that allowed users to log in to various services by using login credentials from another website. But OpenID was very limited, so a group of people working on different authorization protocols for their own sites got together. The first OAuth implementations were done in 2007, and the first revision came two years later.

OAuth 2.0 arrived on the scene in 2010. Its intent was to focus on client-developer simplicity and be more easily scalable while also improving the user experience.

Challenges Ahead?

Although Google, Klout and other big names are implementing OAuth 2.0, there may still be a rocky road ahead fro this protocol. There are criticisms from within the OAuth 2.0 community, including concerns about the protocol’s security (many believe it’s less secure than OAuth 1.0).

According to Hammer, if used by a competent programmer who is well-versed in Web security, OAuth 2.0 works. Unfortunately, only a small minority of developers fit that bill.

In addition, OAuth 2.0 codes are not reusable. For example, OAuth 2.0 protocols used by Facebook would not be readily usable by other site. What’s more, the new protocol is actually much more complex than the original.

But the real kicker for many people is that OAuth 2.0 does not appear to offer any real advantage or improvement over 1.0. Hammer writes that if you are successfully implementing 1.0, there is no reason to upgrade to 2.0.

OAuth 2.0, however, is still very much alive. If it addresses the criticisms and issues being raised, it may still find a place as a very powerful protocol. At the time of writing, however, version 1.0 is still considered the official, stable and tested version of OAuth. Nevertheless, for developers who aim to work with big names in the online world, implementing this protocol securely may become a key skill set in the not-too-distant future.