Without knowing it, my father has skillfully summed up a crisis we are facing online. ‘I have too many $#@%ing passwords’ he told me the other day ‘Just email them to me’. We had just uploaded our latest series of pictures starring his granddaughter. ‘Dad, its real easy. All you need to do is get a Flickr account. Tell me the account name and I’ll share my pictures with the account. Then you can login and look at them online’ I said as if I had just solved all of his problems. But, as I mentioned earlier, he has too many passwords. Too many accounts to remember. Too many places that want the same pieces of personal information over and over again. When he visits he brings his own camera.
The issue is one of those big, nasty problems that would have been solved already had their been an obvious solution. In the internet’s infancy the World Wide Web was just that, a web of interconnected, hypertexted documents. Plain old text-heavy Web Pages which were free to any browser who could connect and request them. Back then, who you were was a very uninteresting question to ask. Web sites didn’t care much what your username was or what street you live on or what your phone number is or who’s in your address book. It is back in this era that the Authentication and State models were developed for the simplest of cases where a sensitive document may have a basic password protecting it. This is years before online Shopping Carts, Home Banking, Corporate Intranets, Web Applications and Social Networks. We are today banging our heads against the limitations of past decisions.
Over time sites started implementing “login” methods as a way to validate users. They all asked the same personal information because no independent website talked with any other. Programmers typically call this a ‘Share Nothing’ approach. As more and more and more and more websites became important in our lives, this share nothing attitude was cause for a growing concern. Your information was being used as currency upon which you were granted services online, grossly inflating the chances of that information becoming misused or abused. Online user accounts were completely disjointed from your actual identity, to where on different sites you may be referred to as “aaronworsham” or “worshama” or “aaronw” or “IndyMusicFan56″ or “MgoBlue1997″ depending solely on what name was free and available at the time. Worse yet, many sites are using your email address for a username, forcing most of us to setup dummy accounts that we must now maintain for password reset requests.
So what is to be done about this? Scary as it may sound, we need to pull away from our “Share Nothing” architecture and start interconnecting these web services. What if my Father had an account at Google for his mail. If Yahoo trusted Google, it could ask Google to “log in” my father so that he could get into the Yahoo owned Flickr site and see his granddaughters pictures. His personal information, including his password, would be housed on Google only. The identity he uses to login could be his Google account or can be related back to his personal blog account or his personal domain name. His identity would remain static. This is the basic idea behind OpenID
The OpenID initiative was started by Brad Fitzpatrick of LiveJournal as a way to start distributing trust relationships for sites like his. In theory it works when one company agrees to be a provider and many companies trust that provider for their authentication. To date many more companies are agreeing to be providers of OpenID than sites willing to trust them. This is still early on, so I feel that this will change over time as more sites start out with the decision that their users do not want yet another place to store their personal information.
Authentication usually has a “on or off” connotation. You are either allowed in or you are not. That need not be the case. Taking the idea of trust relationships further, we imagine using the OpenId model to ask for permission to use services on another site. Take, for example, My father logged into Flickr through his Google OpenID. Now Flickr wants to email out a picture to each of his friends on his email address book. My dad could put all those email addresses into Flickr, but he wouldn’t like it. What if Flickr could use the OpenID trust relationship to ask Google to share dad’s address book. As long as Dad was prompted to provide his password, Flickr itself could be granted limited authorization into google to use dad’s Gmail address book. This is the idea behind OAuth.
The OAuth was a group project between the main engineer at Twitter and some engineers in the OpenID community. The official OAuth site has a good analogy to help get the concepts behind limited system authentication straight
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 your regular key to unlock everything.
These concepts of OpenID and OAuth are even easier to apply to closely controlled interconnected systems like within a company. Sure, most companies have standardized on an LDAP solution by now, but as more applications become web-enabled, it becomes advantageous to consider supporting the standards that the web is using on the outside. Once you try interconnecting your internal applications with outside, 3rd party systems that do not have access to your LDAP repository, you will want that trust relationship model OpenID and OAuth brings.
Technorati Tags: OpenID, OAuth, authentication
Sphere: Related Content
I got the change to talk with 
