The social media explosion has allowed businesses and individuals to present themselves in many new and interesting ways, but it's also taken the challenge of managing one's digital identity from merely "difficult" to something approaching "I give up." Whether one uses cloud-based services for content management, marketing and sales efforts, or just sharing photos from a company event, one can't count on the IT department for help in managing the ever-increasing number of credentials that are necessary.
It's possible - with the help of a lot of sticky notes - to keep track of a multitude of user IDs and passwords. For the digitally connected, it's now commonplace to present one's login from an established site, such as Facebook, Google or Twitter, especially when accessing a service that uses data from one of those online cornerstones.
For most of us, this "just works" and once we're set up, we go on to sharing photos, or tweets, or whatever. But much of this ability to easily access a service without setting up yet another ID and password rests on a little-known protocol, called OAuth.
OAuth (as in "Open Authorization") traces its beginning to the fall of 2006, when implementers of OpenID, including Blaine Cook, Twitter's lead developer at the time, Larry Halff of what is now Gnolia, Chris Messina, now with Google, David Recordon of Facebook, and others began discussing ways of delegating authentication through an API. Within a year, a draft of the core specification was ready for release. Since then, the specification has had its tires kicked in a number of implementations, and since last year, a working group of the Internet Engineering Task Force (IETF) has hashed over issues that must be resolved before OAuth can be properly considered a standard.
This spring, things really began to move for OAuth. Enough changes had come out of the working group to justify a "2.0" label, which appeared on a fresh draft of the specification that was posted to the IETF wiki on April 22. Earlier that week, Facebook CEO Mark Zuckerberg announced at the company's F8 developer conference in San Francisco that, as part of the introduction of its Open Graph package, the company was "eliminating the Facebook Connect brand" and implementing OAuth as its chosen authentication method. At the risk of going overboard, OAuth appears to be the hottest thing in identity management.
OAuth's supporters often compare the protocol to the valet key of a luxury car; such a key allows a parking attendant to use the car in a limited fashion, barring access to trunks or onboard phones, and restricting the operating radius of the car to a mile or two. In a similar fashion, OAuth enables end users to present identity credentials from one site or service, and grant another service access to data on the first site, without exposing one's password to the second site.
Eran Hammer-Lahav, director of standards development at Yahoo and editor of the OAuth specification, explained that everyone wins in this scenario, because "you get to create a best-in-breed application by combining all the different pieces that you prefer. You move around this environment with an identifier that brings with it all this data, or at least, glues it together so that each service can find everything else."
To the casual observer, this may sound a little like what we were promised with single sign-on (SSO), but that's not at all the case, said Hammer-Lahav. For one thing, the OpenID protocol would be a better comparison with SSO, and OAuth doesn't actually require OpenID at all.
For another, OpenID's usefulness is in maintaining user logins across multiple sites, whereas OAuth removes the need to present that login to any site except the identity provider's. In practice, OpenID and OAuth complement each other, noted Hammer-Lahav. He added that some of OAuth's proponents, including Facebook's Recordon, have suggested treating identity verification as a resource, and thereby redefining OpenID as a layer on top of OAuth.
Hammer-Lahav claimed that SSO by itself "doesn't really add that much value, even if you look at enterprise environments." One of his previous employers "had about 50 different internal systems; they tried to build a single sign-on system for everything and at most, the value was that you didn't have to remember 50 passwords, but you still had to log in 50 times."
Finally, he added, SSO functions have been overtaken by the way that people use software; "most users log in because their browsers remember their passwords, and it works pretty well."
As analyst Michael Cot??Â« of RedMonk explained, "integration is the constant challenge with any type of identity management, whether it's consumer or enterprise. You could have 95 percent of the different services integrated, and no one's ever going to notice, but they're going to notice the 5 percent that are not, and they're going to think that nothing's integrated."
In Hammer-Lahav's view, a simple - yet secure - authentication and authorization process is essential for applications and services on the Web. "Anything that slows down the login experience is usually bad; it costs you in [lost] users," he pointed out.
Although one might think that such mechanisms would be of key interest to enterprise security vendors, they're nowhere to be found for much of the discussion. "Enterprise identity management has kind of dropped the ball as far as advancing identity management," said Cot??Â«. "For the most part, the interesting work in identity management gets done by consumer sites" such as Facebook and Twitter.
Perhaps it's just as well, because with applications in the cloud, the landscape of identity and security is a world turned upside down. "How much you share is a new question for identity management," Cot??Â« noted. "Identity management, classically, is primarily about security and making sure hackers don't do something. It's about making sure the right person does the right thing. Identity management in the Facebook age is exactly the opposite; it's about making it as easy as possible to share the maximal amount of information."