OAuth: Giving Access to the Castle without Losing Control

By Ben Gross

Subscription Options

As online services such as Webmail, photo sharing sites, social networks, and browser-based office suites grow in popularity, we store more and more data in the “cloud.” The problem is: Data in the cloud is often just as incompatible and inaccessible as data in traditional client applications. OAuth provides a mechanism for services and applications to easily and securely share data and features.

Eran Hammer-Lahav, who was involved in the OAuth specification early on, likens OAuth to a valet key used in luxury cars. The valet key allows someone to park the car, but not necessarily to access the trunk or other car electronics, such as the integrated mobile phone address book. Online address books for Webmail and lists of contacts in social network services are common types of data we might wish to share across services. Until very recently there have been few ways to share contacts across consumer services, which has led to a nearly pervasive workaround that is a genuinely bad idea for a number of reasons.

Here is how the workaround is typically handled. Alice has an account with ExistingSocialNetwork.com where she has lots of friends and contacts. Alice has signed up with NewSocialNetwork.com, but balks at the idea of manually reentering the 112 friends she would like to migrate to the new service. What NewSocialNetwork.com does is offer Alice an interface to import her contacts from ExistingSocialNetwork.com simply by providing her credentials for that service. A minute later all of her contacts are imported into the new service and Alice is happy.

So what’s the problem here? To recap, the first service requested that Alice enter her login and password for the second service and then used these credentials to extract the contact information from the first service. This is bad for the following reasons:

Security: Nearly every example I looked at caused the user to type in the login and password over an insecure connection, even if the original service provider had a secure login method by default.

Revocability: Once the user has provided credentials for the first service, there is no mechanism from preventing the second service from caching and reusing those credentials at a later date aside from changing the password on the first service.

Limit Scope: There is no way for the user to know if the service extracting the data will extract addition data beyond what the user requested.

User Behavioral Training: This practice makes the user accustomed to entering credentials in locations other than ones provided by the vendor without the normal security protections.

Privacy: The user must provide their identity on the first service as part of the credentials in order to allow the second service to extract the data.

What OAuth Does

OAuth is a simple standard for one service to provide access to resources such as contacts, photos, or other data to another service or application. Users can revoke access at any time and do not have to reveal their credentials, only a potentially anonymous token, to the requesting service or application. Access is granular—providing the requesting service access to your address book does not also give that same service the ability to post to your blog or view your advertising revenue.

What this means is that Web-based services and applications now have a potential way to solve the problem of Alice exporting her contacts from one service to another in a way that is secure, revocable, limited in scope, more private, and encourages good user behavior. OAuth does not attempt to solve other problems that can arise such as privacy policy management or data duplication and skew.

In my last Messaging News column I wrote about OpenID authentication framework and the challenges it faces to become a mainstream Internet-scale Single Sign On (SSO) mechanism. While OpenID focuses on authentication, OAuth focuses on authorization. Often descriptions of authentication and authorization are conflated. The two mechanisms are intimately connected, however it is important to distinguish one from the other. The descriptions are often further confused as the documentation may refer to “API authentication” and when simply using authorization or access control would be a clearer description.

Authentication is the process where a person (although it could be a computer or other device) presents a series of credentials, such as a username and a password, and those credentials are verified against an authoritative source. If all the credentials verify correctly, then the system considers the identity verified. (Note: While a wide variety of mechanisms from tokens to biometrics could be used as stronger credentials, it is not important to this example.)

Authorization is the mechanism that determines what resources a verified identity has access to. For instance, Authorization is the mechanism that determines whether or not your authenticated identity should be able to access only your salary information in the HR database or the salary information of everyone in the company. Authorization is often implemented as access control lists (ACLs), such as in file systems or keyless entry systems.

The first public draft of OAuth was released in September 2007 and the final draft of OAuth Core 1.0 was released in December 2007. Additional OAuth mechanisms are in the process of standardization. For example, there is a draft specification for the OAuth Discovery protocol should simplify the configuration of OAuth enabled services. There are OAuth API libraries for most languages commonly used in Web development including Python, PHP, Ruby, Perl, Java, C#, and Objective-C.

Background to OAuth

There are a number of modern predecessors to OAuth including Flickr Auth, Yahoo’s BBAuth, Google’s AuthSub, and AOL OpenAuth. Compared to OAuth, each of these mechanisms has slight variations, advantages, and disadvantages. OAuth is vendor agnostic, which is a major advantage for developers who would otherwise need to support each vendor’s authorization mechanism (assuming they have one). OAuth is designed as an authorization solution for consumer services and applications. Enterprise standards for authorization as part of the Web Services (WS-*) collection are still in flux and span a number of specifications.

The authors of the OAuth specification looked at the functionality of existing systems and attempted to reuse as much functionality from existing implementations as possible. Many of the systems combine authentication and authorization. However, OAuth is designed to assume that authentication is handled by another mechanism.

Yahoo! began to support OAuth in March 2008 for its Fire Eagle location-based service. In June of 2008 Google announce support for OAuth in all of its Data APIs (GData). Additional companies that have current implementations of OAuth include: Get Satisfaction, Ma.gnolia, PhotoBucket, and SmugMug. Numerous other companies demonstrated experimental implementations at the recent OAuth Summit. The number of OAuth enabled services from both large and small providers will expand substantially in the next six months.

OAuth is an important contribution as it is a vendor-neutral specification for Internet-scale delegated authorization. The first draft of the OAuth specification is complete. There are libraries for most common languages used in consumer Web services, as well as a number of implementations on popular consumer services. However, the specification is still in its early stages and there are many open questions, and problems to solve—such as how to improve the user experience, and extensions to be standardized to make the specification easier to use and more simple to deploy.