OAuth and OAuth WRAP: defeating the password anti-pattern

The developers behind the OAuth standard have introduced a new variant called …

The developers behind the OAuth protocol have developed a new variant called OAuth WRAP that is simpler and easier to implement. It's a stop-gap solution that will enable broader OAuth adoption while OAuth 2.0, the next generation of the specification, is devised by a working group that is collaborating through the Internet Engineering Task Force (IETF).

Understanding the password anti-pattern

Many popular Web applications allow third-party software to access their underlying services through open APIs. This enables the development of Web mashups and mobile and desktop client applications. Although these open APIs bring a lot of value to the Web and make it possible for various services to interoperate in important ways, it can be difficult to make this functionality available in a manner that safeguards the security of end users.

The APIs often require authentication for sensitive or user-specific features. For example, in order for a desktop application to be able to access a user's account on a hypothetical Web service, the user must first supply the application with their login credentials. The application can only access the user's account if it transmits the user's credentials to the server.

Although this form of simple login-based authentication is very easy to implement, it creates a tremendous number of problems. One of the biggest issues is that there is no easy easy way for the user to revoke access permissions from an individual application. It can be especially difficult to remove your credentials from third-party Web applications, which you can't just uninstall.

When third-party software runs amok with your login information for a Web application, the only way to stop it in some cases is to change your password. Another problem with simple login-based authentication is that there is no way to control how much access an individual third-party application gets: it's an all-or-nothing deal based on whether you are willing to give the program your password.

What users need is a granular authorization system that will allow them to selectively grant revokable privileges to individual applications without having to supply a global password. Several popular Web applications, such as Facebook, have implemented their own authentication systems that aim to do precisely that.

But for application developers who want to make their software work with a variety of popular Web services, it's not especially pleasant to have to work with a variety of different authentication systems. Obviously, what developers need is a standards-based solution. That's where OAuth comes into play. It's the first step towards delivering a standard protocol for password-less Web authentication that works across the Web and the desktop.

OAuth has not been widely-adopted yet, but it has gained traction in some environments. Twitter and Digg both have experimental support for OAuth and both services plan to make it mandatory for application authentication in the future. Unfortunately, the current version of the standard—1.0 revision A—suffers from a number of deficiencies that make it burdensome for application developers to support.

OAuth 1.0, an inelegant solution to a difficult problem

OAuth was created by some of the some people who developed OpenID, but it's important to understand that the two protocols are fundamentally different in some key ways. OpenID is a solution for Web-based single sign-on whereas OAuth is for making secure resources in a Web application accessible to third-party software, including desktop applications. There is a certain degree of overlap, but the two standards are complementary rather than competitive.

The OAuth protocol is complicated and a full explanation of how it works is beyond the scope of this article. We are just going to look briefly at the general flow of the authentication process. Yahoo has a reasonably accessible overview that I recommend reading if you want a more detailed and developer-centric technical introduction.

The client application asks the server for a request token.

The application directs the user to a Web page on the server where they can agree to authorize the desktop application. The request token that was obtained from the server is supplied as a parameter in the URL that is used to direct the user to the authentication page.

When the user authorizes the application, the server provides a verification code.

The application trades the request token and the verification code for an access token

The application can now use the access token to interact with the Web service. Tokens are generally set to expire at routine intervals and must be renewed periodically.

The general process as described above isn't too bad, but it's encumbered with a lot of other complexity that makes the protocol painful to work with. At every step of the authentication process and in every API call, the application has to provide a number of other parameters including timestamps, nonces, and a cryptographic signature. This is done so that the API calls can be transmitted across the wire sans SSL without compromising the user's security.

The protocol is challenging to implement properly. The existing libraries lack maturity and are significantly under-documented. These issues are problematic because they create a higher barrier to entry for application developers who want to use Web APIs that require OAuth for authentication.

Another problem with OAuth is that its reliance on browser-based authorization poses challenges for desktop, mobile, and embedded applications that are not running in the user's browser. A Web application can use simple redirects, but a desktop application has to rely on a Web browser or have an embedded browser in order to facilitate authorization. The standard approach is to provide a URL for the user to visit in an in external browser and then require the user to copy and paste a key value back into the desktop application. This process is highly unintuitive and can be prohibitively difficult in some environments—particularly mobile devices or set-top boxes.

One of the major factors that has driven Twitter's success is the rapid proliferation of third-party tools—a trend that was made possibly by Twitter's extraordinarily simple API. Using HTTP "Basic" authentication, I can post a message to Twitter with only one line of Python code. Doing the same thing with OAuth requires significantly more code, even if I use an existing OAuth Python library. If Twitter follows through with its plan to mandate OAuth, it could stifle the growth of the ecosystem of third-party tools.

OAuth 1.0a certainly defeats the password anti-pattern, but it's a suboptimal solution in some very frustrating ways. Fortunately, key people behind the standard are aware of these issues and are working to find solutions.

OAuth WRAP and OAuth 2.0: making a better solution

The OAuth Web Resource Authorization Protocol (WRAP) is a simplified variant of OAuth that aims to reduce the complexity of the protocol. It eliminates the need for OAuth's signatures by requiring communication to take place over SSL-encrypted connections—effectively moving encryption to a lower level of the stack where it can be handled natively by the networking libraries that are already used by the application. Facebook's David Recordon, one of the creators of OpenID and OAuth, shared some details about OAuth WRAP in a recent article at O'Reilly Radar.

"WRAP attempts to simplify the OAuth protocol, primarily by dropping the signatures, and replacing them with a requirement to acquire short lived tokens over SSL. [...] Using SSL obviates the primary purpose of the cryptography used in OAuth 1.0a, which was designed for transferring data over insecure channels," he wrote. "Unlike 1.0a where the server issues and verifies every token, the tokens in OAuth WRAP are short lived and can represent claims issued by an authorization server, providing scale and security benefits for large operators."

Bret Taylor, director of products at Facebook and former CEO of FriendFeed, recently wrote a blog entry that describes a bit more clearly how OAuth WRAP works in practice. After the application goes through the steps to obtain the access token, it can simply supply that token as a URL parameter in SSL-encrypted API calls. He says that adding OAuth WRAP support to FriendFeed was easy and that it can coexist with the regular OAuth implementation that the service already supported.

"I was able to implement WRAP on top of our existing support for OAuth, using the same tokens for both. As a consequence, our existing user interfaces for revoking applications work whether an app is using OAuth or OAuth WRAP. If we hadn't implemented OAuth support, OAuth WRAP would have been much easier to implement on its own because it is stateless; the verification code / access token exchange is so much simpler than the OAuth token exchange protocol."

OAuth WRAP looks like a much better approach than OAuth 1.0a. As an application developer, I'm very happy to see the protocol moving in this direction. It seems like a good, pragmatic balance of security and ease of development. Not everybody agrees, however. Some critics, like security researcher Ben Adida, contend that it's unwise to depend on SSL because you can't count on application developers to configure it properly and use it consistently.

"That we would introduce a token-as-password web security protocol in 2010 is somewhat mind-boggling," he wrote. "I see reasons to simplify OAuth. Maybe rethink the combination of consumer and access secrets, which is a bit messy. Maybe rethink the token renewal process and make it part of the core. But removing signatures? I think this is asking for long-term trouble in exchange for a modest amount of short-term simplicity."

Growing adoption and the future of the protocol

As Recordon explained in his article, a new version of the protocol—called OAuth 2.0—is being developed through IETF with the aim of making improvements based on feedback from the industry and some of the lessons that were learned during the making of OAuth WRAP. He also says that the developers are looking at ways to improve the authorization experience for devices and desktop applications.

"In many ways, OAuth 2.0 will be the result of combining the best ideas from both protocols. The authentication part will built on top of 1.0a while the authorization part will build on top of WRAP. It is important to remember that it is very early in the process, and that all these decision will be made by the members of the IETF OAuth working group. In other words, by those who show up. The goal is to have a set of stable drafts for OAuth 2.0 by the upcoming IETF OAuth Working Group meeting in March at the 77th IETF meeting."

OAuth is starting to attract considerable interest from heavyweights of the Web world. The working group includes representatives from Facebook, Google, Microsoft, Yahoo, and other companies. Facebook recently announced that it plans to adopt OAuth WRAP for its Facebook Connect login service, replacing its own proprietary framework. Although OAuth 1.0a leaves a lot to be desired, the protocol is maturing and becoming an increasingly desirable solution for standards-based password-less authentication.