Corvus Consulting

This is the second of four posts about passwords as a technology, and examines OpenID and OAuth as ways for web services to improve the user experience and safety of password use online. Other parts of the series are linked from Part 1.

Much of the discussion over the state of password use on the web focusses on the practices of users: how much they re-use their passwords, how weak or strong the passwords are. These concerns are valid, of course, but they imply that the risk exposure found in current practices comes with the territory, and that users never change. This perspective ignores the wider issue, which is that the dominant authentication model in use in web applications today carries these problems inherently when brought to the web. What some smart people are trying to do now is to change the model itself as it’s implemented by web services, replacing it with something that not only mitigates some of the problems with passwords, it makes them go away entirely.

There are two technologies that stand to greatly simplify the complexity of password authentication on the web: OpenID and OAuth (for Open Authentication). Both are, as the names imply, open and free of proprietary control, and their technical details are public. OpenID and OAuth are long-haul solutions. They have the potential to bring greatly improve the state of passwords as a practice on the web, and while they are growing in adoption, it will take a while to get there. Some web services never will. They don’t solve every potential problem out there, but they go far enough to get us to a stable footing in password practices, and are worthwhile in that aspect alone.

However, they do require work to integrate into a website, and ideals can become timid in the face of tight deadlines and budgets. Not many managers of web services would immediately want to take on the effort to convince users and third party developers to change how they do authentication. Moreover, if there hasn’t been a major problem with passwords so far, the sentiment that ‘if it’s not broke, don’t fix it’ is likely to prevail. So if it’s such a hard sell, why put stake in these ideas? How much of a difference can they make?

As it happens, that’s exactly what the rest of this post is about.

OpenID

OpenID seeks to eliminate the creation of new passwords, and to centralize the management of all authentication for a person at a single point that is under their control. This point of control is called the OpenID provider. Most people get their OpenID from a provider service. Others, however, act as their own provider, giving them total control over their OpenID identity. A number of popular blog engines have OpenID plugins that do just this – make you your own mini OpenID provider. Self-management, while an interesting option, isn’t necessary to get the benefits of OpenID.

An OpenID is typically an URL. If your provider is ClaimID (mine is), then yours might look like http://claimid.com/tsieling (if your name was close to mine). When you sign into a site using OpenID, you just give them your URL. The site you’re signing into then takes you to your OpenID provider page, where you sign in to your OpenID. The OpenID provider will tell the website that you’re for real, and voila, you’re signed in.

I cooked up a simple diagram that shows the flow of actions in an OpenID authentication from the user’s perspective:

The key benefits of OpenID are very, very strong:

* The sites you sign into never see your password

* You control the OpenID

* For every OpenID site you join, you don’t need to make a new password

There are, however, some down sides to the OpenID experience that need to be noted:

* If your OpenID server has a problem, you can be locked out of a bunch of websites until it’s fixed

* If someone gets your OpenID password, your data is at risk at all the OpenID supporting sites you use

* The user experience involved with the OpenID implementations I’ve seen so far, including the one I helped design for Ma.gnolia, can be disorienting to new users who don’t know how to react when taken to another website to sign in. New users really need to be better escorted through this process the first few times.

OAuth

OAuth is still warm out of the specification-making oven at this writing, but it has a great lineup of support commitments already, including Ma.gnolia. The spec goes a long way to solve the problem of giving your password to another service so you can use two web services together, and opens up a world of safe integration with third party applications to web, desktop and mobile application developers.

What does it do? The formal term is delegated authentication. The canon example is giving a photo printing service like Moo.com the password to your photo sharing website, like flickr.com. Another example is giving a social networking site the password for your webmail address book so they can invite your friends, like Quechup. Handing out passwords to third parties increases the number of places they are stored, and from that the number of points from which they could escape into the wrong hands.

In cases like Moo and flickr, the service cooperation works great and the permission to interact is maintained. But, what if the other site that you gave your address book password to, say, spams the daylights out of your friends? To block their access, you’ll need to change the password at all the services that did nothing wrong. It’s kind of offensive, at several levels.

OAuth makes short work of this problem by specifying a process for telling a service provider that another application or website should have access to your stuff. Like OpenID, it’s not a cure-all for every possible attack out there, but it does cover a great deal of ground in one leap. I have a second diagram that shows the flow of interaction with a user granting access to an application using OAuth.

The key benefits of OAuth are profound:

* Open source solution for authenticating third party applications – a dream for developers

* No passwords are given to third party applications

* User controls access on a per-application basis

* Different levels of access and read/write permissions can be given on a per-application basis

* All authentication stays with the service provider

* Opportunity to provide interaction with innovative and popular web, desktop and mobile applications

The drawbacks? Well, OAuth is new, so code libraries are still being written and tested. The body of experience in implementing OAuth isn’t there yet, so early adopters are going to be doing more legwork. However, the opportunities and benefits make OAuth an easy sell, as the problem it solves is one that nobody wants to try facing alone.

Conclusion

Clearly, I see a great deal of potential in both OpenID and OAuth. I’ve had the opportunity to help bring OpenID into Ma.gnolia, and we’ve only seen a positive impact from it. We’ll be among the first to implement OAuth as well. Having participated in editing the spec, I can speak to the clarity and flexibility of OAuth as a way of allowing applications to safely act on behalf of a service provider’s customers. As more web users become familiar with these technologies, and as the user experience they provide is refined, the safer those people will be in their discovery of ever-more interesting ways of using the web.