OpenID appears to be red hot right now. The adoption of this emerging standard has accelerated in the first half of 2008 as it has entered the radar screen of web developers. Many large organisations, such as Google, Yahoo, IBM, Microsoft and AOL provide OpenID servers. Popular Internet sites, such as LiveJournal, Blogger, Jabber, Drupal and Wikitravel support OpenID logins, and the list is growing. Browser support for OpenID is just around the corner (it’s a feature in Firefox 3 for example). But we are getting ahead of ourselves. What is OpenID and why is it good? Put simply, OpenID solves two common problems; that of having to manage multiple accounts on different websites and that of storing sensitive account information on websites you don’t control. With a single OpenID account you can log into hundreds of different websites. Best of it, you -the user- manage the account information, not the website owner. In more technical terms, OpenID is an open, decentralised, user-centric digital identity framework. I’ll explain this in some more detail.
OpenID is an open standard, because nobody owns it and because it’s free of patents and commercial licensing. The standard is maintained by the OpenID foundation; free open source implementations are available in many languages, including Java and PHP. It is decentralised, because it does not depend on a specific domain server. An existing OpenID provider can be rerouted very easily, as we shall see. It is user-centric, because it allows users to manage and control their identity information. Users can identify themselves with a URL they own. While traditional authentication relies on a combination of either a name or an email address and a password, OpenID just requires one item which is either a URL or an XRI (extensible resource identifier). To understand how this works, let’s look at the OpenID protocol and see what an OpenID login procedure actually does.
Let’s assume you already have an OpenID. You can use the same OpenID with any OpenID-enabled website (called the “relying party”) by typing it into the OpenID login field or by letting your browser fill out the field automatically. When you click Submit, the relying party performs a “discovery” procedure to retrieve an authentication URL and subsequently performs an “association” procedure for secure information interchange with the OpenID provider. You are then transported to the authentication URL (called the “OpenID provider”). Normally this is a site like yahoo.com or myopenid.com, but nothing keeps you from running your own OpenID server. After authenticating at the OpenID provider’s secure login page, you are redirected back to the relying party. If the relying party has requested identity information (name, gender, birth of date, etc.), you are prompted which information should be sent to the relying party. Often this information is used to fill in a registration form at the relying party. This information isn’t retrieved for a normal login, but the OpenID protocol supports it. Once you are back at the relying party’s website, the relying party checks whether the authentication was approved and verifies that the information is received correctly from the OpenID provider.
It sounds slightly complicated and by looking at the OpenID specifications you will find that the protocol is indeed quite involved. However, from the users point of view, it is really simple. The user only sees the OpenID login screen. If the user has enabled automatic login at the OpenID provider via a certificate or cookie, the only screen the user sees is the “approve/deny” screen. Logging into a website could not be easier. Only one password needs to be remembered. Registration forms can be pre-filled. Login into specific sites can be fully automated. The best thing is that the user has full control over the OpenID provider thanks to the discovery process. During discovery, the relying party looks for two fields in the header of the web page that it finds at the OpenID URL. In HTML Discovery, there are two fields named openid.server and openid2.provider.Example:
<link rel="openid.server" href="http://www.myopenid.com/server" /> <link rel="openid2.provider" href="http://www.myopenid.com/server" />
These two entries commonly point to the same end point (the OpenID provider) and are used by version 1 and version 2 of the OpenID protocol. If you have a website, you could simply edit the HTML of your site to add these entries into the HTML header. You could then use the URL of that page as your OpenID. The advantage of using your own web page is that you control the OpenID end point. Hence, you can switch OpenID providers while retaining your OpenID simply by editing your site’s HTML code.
If you are going to incorporate OpenID into your existing website, you might want to think twice about implementing the protocol yourself. It isn’t trivial, and there are already several open source libraries that can be used, e.g. Openid4java if you program in Java, or the JanRain PHP OpenID library which works with PHP 4.3 up. Additional libraries for these two languages, as well as Ruby, Python, C#, C++, and other languages can be found at http://wiki.openid.net/Libraries.