With OAuth 1.0 Draft due out next week, I wanted to introduce the protocol and try to help people understand what it is and what it is trying to solve. OAuth (pronounced “Oh Auth”) is mentioned is many blog posts, usually in the context of OpenID and Open Social Networks. While OAuth can play an important role in helping open up closed communities, it is not specific to social networks. The short(est) explanation of OAuth is ‘An API access delegation protocol’. Now for the longer one.

A Little Bit of History

OAuth started around November 2006, while Blaine Cook was working on the Twitter OpenID implementation. He got in touch with Chris Messina looking for a way to use OpenID together with the Twitter API to delegate authentication. They met with David Recordon, Larry Halff, and others at a CitizenSpace OpenID meeting to discuss existing solutions. Larry was looking into integrating OpenID for Ma.gnolia Dashboard Widgets. After reviewing exiting OpenID functionality, as well as other industry practices, they came to the conclusion that there was no open standard for API access delegation. The conversation continued online and off for a few months.

In April 2007, a Google group was created with a small group of implementers to write a proposal for an open protocol. It turned out that this problem wasn’t unique to OpenID and when DeWitt Clinton from Google caught wind of the project, he  expressed his interest in supporting the effort, if only as a stakeholder. In July 2007 the team drafted an initial specification and the group was opened to anyone interested in contributing. After many online and face to face discussions, the OAuth 1.0 Draft is due out next week.

What is it For?

Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what 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.

Everyday new website offer services which tie together functionality from other sites. A photo lab printing your Flickr photos, a social network using your Google address book to look for friends, and APIs to build your own desktop application version of a popular site. These are all great services – what is not so great about some of the implementations available today is their request for your username and password on the other site. Using Twitter as an example, the site simple yet powerful API created a rich community of applications built on top of its platform. But in order for those applications to update your status on Twitter, they must ask for your password. When do so, not only you expose your password to someone else (yes, that same password you also use for online banking), you also give them full access to do as they wish. They can do anything they wanted – even change your password and lock you out.

This is what OAuth does, it allows you the User to grant access to your private resources on one site (which is called the Service Provider), to another site (called Consumer, not to be confused with you, the User). While OpenID is all about using a single identity to sign into many sites, OAuth is about giving access to your stuff without sharing your identity at all (or its secret parts).

OAuth and OpenID

OAuth is not an OpenID extension and at the specification level, shares only few things with OpenID – some common authors and the fact both are open specification in the realm of authentication and access control. ‘Why OAuth is not an OpenID extension?’ is probably the most frequently asked question in the group, and also my first when I joined the OAuth effort. The answer is simple, OAuth attempts to provide a standard way for developers to offer their services via an API without forcing their users to expose their passwords (and other credentials). If OAuth depended on OpenID, only OpenID services would be able to use it, and while OpenID is great, there are many applications where it is not suitable or desired. Which doesn’t mean to say you cannot use the two together. OAuth talks about getting users to grant access while OpenID talks about making sure the users are really who they say they are.

Who is Going to Use it?

If you are a web developer – you, we hope. At the time of writing this, we expect initial implementations from (in alphabetical order) Digg, Jaiku, Flickr, Ma.gnolia, Plaxo, Pownce, Twitter, and hopefully Google, Yahoo, and others soon to follow. Given my personal focus on micro-blogging, it is particularly gratifying to contribute to a service that will be used by three leaders in the space, Jaiku, Pownce, and Twitter. Nouncer will obviously support it when its launched.

Isn’t This Just Like…

Yes! And no. OAuth is the standardization and combined wisdom of many well established industry protocols. It is similar to other protocols currently in use (Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Upcoming API, Flickr API, Amazon Web Services API, etc). Each protocol provides a different method for exchanging user credentials for an access token or ticket. OAuth was created by carefully studying each of these protocols and extracting the best practices and commonality that will allow new implementations as well as a smooth transition for existing services to support OAuth.

An area where OAuth is more evolved than some of the other protocols and services is its direct handling of non-website services. OAuth has built in support for desktop applications, mobile devices, set-top boxes, and of course websites. Many of the protocols today use a shared secret hardcoded into your software to communicate, something which pose an issue when the service trying to access your private data is open source or hackable.

Once Upon a Time

This is – in brief – how the story goes. I’ll try to sum it up using a website example. You the User log into a Consumer website asking it to do something for you using your Protected Resources on another site (Service Provider). The Consumer sends you over to the Service Provide with identifying information about it and what it is trying to access. When you get to the Service Provider you sign in and are asked if you want to let the Consumer access. Only if you agree will the Service Provider send you back to the Consumer with a special Single-User Token. At this point you as a User are done. The Consumer will now take the Single-User Token and contact the Service Provider to exchange it for a Multi-Use Token, the “ticket” it can use from now on to access your Protected Resources on your behalf. This is of course a simplified flow, not detailing the security and verification measures the protocol includes.

Tokens can live forever, have a limited lifetime, or be restricted to some activities. For example, a Token can allow the Consumer to change your data, while another Token is only good for read-only access. A printing service accessing your Flickr photos should really only have read access, while a new red-eye correction service will need write access to change the photos.

Now What

In the next few days the OAuth 1.0 Draft specification will be released on the upcoming community site http://oauth.net. The goal is to have as many people review it and start implementing it – after all, the best way to review a protocol is to implement and play with it. Early October or based on progress made, the specification will (hopefully with minor changes) become final as OAuth 1.0. An announcement will be posted on the community site (and of course here) when it is ready for public eyes. If you want to get your hands dirty right away, join the Google group and help out. Right now beside proofing the draft, help is needed in writing guides and code.