The process of users identifying themselves is practically ingrained in an application's workflow, where as integrating this username/password functionality has also become a better part of the A-B-C's to creating software. However, this last process is often abhorred by many, for users the "yet another username/password" is often viewed with angst given the growing number of credentials they need in the digital world, something that also makes software stakeholders and designers weary in turning away users on account of requiring "yet another username/password". So up next, we will explore one initiative named OpenID that aims to reduce this particular burden through the use of Web services.
OpenID works by allowing users to store their credentials in the 'cloud' and application providers the capability to leverage these same identities in an application's workflow. It's a win-win situation, one where users don't have to remember multiple login credentials while navigating different domains. Application providers are spared the trouble of maintaining a data store of this type and alienating users through the creation of a new username/password combo.
From an end user point of view, what characterizes OpenID is its decentralized design, something which translates into users having complete control over where and in what fashion their information is stored, a process that is in stark contrast to other identity systems on the Web such as Microsoft's Passport where all information is held by a single entity, in the latter case a private company. At an organizational level, OpenID has the capability of being spun off under its own infrastructure, allowing companies to keep a tight lock on username/password while allowing departments or partners access to these credentials.
Now that we've covered the theory, let's explore the actual steps involved using an OpenID service. Assume you've arrived at point in your application's workflow where you require a user to identify himself, you would then present a user with an OpenID prompt, at which point the user would enter his OpenID, which would resemble a URL, like so : https://me.yahoo.com/a/john_doe. The user would then be redirected to his OpenID provider to identify himself as john_doe, and, if successful, the OpenID provider would then deliver a token to your application confirming the user's identity. The following figures illustrates this process:
At this point, you only have a token and absolutely no information about the particular user, but you have a password-backed identity on which you can now start collecting data, be it name, address or any other personal information you wish to request. You're still prone to loose users if you overburden them with further questions. You've eliminated one big hurdle to getting people's foot in the door of a new application, not forcing them to create "yet another username/password".
Under the hood, this whole OpenID identification process takes the form of multiple Web services communicating with each other to fulfill the loop. You can find a series of OpenID libraries to help you implement OpenID in languages ranging from Java, Python, PHP, C# and Perl, among others. Equally, if your organization is looking to deploy its own identity server to supplement or supplant something like LDAP with OpenID, you can also find a series of Identity Servers written in different languages and targeting different needs.
Finally, as with most emerging technologies comes the typical dilemma: providers will support OpenID if there are enough users and users will opt for OpenID as long as there are sufficient providers. So were does OpenID support stand at this moment? Well, if you looked closely at the images presented previously you may have noticed Yahoo! was the OpenID provider, a company which is perhaps the biggest endorsement the OpenID initiative has received to date, given the market penetration and millions of user accounts this last company manages. And joining the ranks of Yahoo! supporting OpenID are also companies with ample user bases like AOL, France Telecom(Orange), WordPress, and of course, lets not forget the power of one. Any company can be its own OpenID provider and offer the same functionality as these larger providers.
So whether you're looking to completely absolve an application's design from user/password issues or searching for an identity management technology for your organization that is gaining traction in the industry, OpenID provides an excellent solution which is underpinned by the same principles present in Web services. It's one choice your end users will appreciate when they realize they won't have to remember "yet another username/password".
About the author
Daniel Rubio is an independent technology consultant with over 10 years of experience in enterprise and web-based software, he blogs regularly on these and other software areas.
