Author: Nathan Willis
As the most basic level, your OpenID identity is a unique URL. It can be a URL that you directly control (such as that of your personal Web page or blog) or one provided to you by a third-party service, such as an OpenID provider. In that sense, a site’s use of OpenID identities is no different than using email addresses as identifiers: they are unique to each user and are verifiable. But you can publicly display an OpenID identity without attracting spam.
Using your OpenID to sign in to a compliant site involves four parties: you, whatever site hosts your OpenID URL, the site to which you are signing in, and an “identity server” which brokers the authentication between you and the site to which you are signing in. In the official OpenID parlance, the site to which you are signing in is referred to as the “consumer.”
Since OpenID is designed to be completely decentralized, you have some options to whittle the above list down to three players instead of four. If you run your own Web server, you can use your site to both host your OpenID URL and run your own identity server. Alternatively, if you create an account on one of the public OpenID providers, that provider can both host your OpenID URL and act as the identity server.
The latter option is certainly less work for the novice. Run out and register an OpenID right now. Pick any one of the OpenID providers listed at the openid.net wiki and set up an account. You will probably have to use email verification to do so, but once you are finished you will be the proud parent of an OpenID URL — something to the effect of http://yourname.someOpenIDprovider.com — with which you can see how the login process works, first hand.
Trying it out yourself is far better than reading the voluminous overview documents available on the various OpenID sites. For one thing it dispenses with the convoluted abstract naming of the protocol spec, and for another it lets you see how OpenID is used for the login process at a real-world consumer site, and how that differs from other account setup and maintenance features.
First run
Take a look at the page at http://yourname.someOpenIDprovider.com. In most cases is it is a simple page with little more than “this is an identity page for user yourname” and a few links to FAQs about OpenID. But in the HTML source itself there is a key tag in the header in the form <link rel=”openid.server” href=”http://someOpenIDprovider.com/server” />. That tells inquiring consumer sites where to connect to verify your identity. So pick a site, and log in.
Spotting OpenID-enabled sites in the wild is easy: almost all utilize the OpenID logo on their login form; the little orange and gray arrow is designed to be a signpost much like the ubiquitous RSS symbol. For our purposes, you can choose any OpenID-enabled consumer site to log into. Take the openid.net wiki, for example. The login page is reachable from every page in the wiki, and consists of just one field: your OpenID identifier. Type in the OpenID URL you were assigned by the OpenID provider you signed up with, and click the login button. Now the action starts.
The openid.net wiki makes sure the URL you typed is valid, then fetches the page and looks for the rel=”openid.server” tag. It then contacts the server specified in that tag and asks about your OpenID URL. It is then up to that server to authenticate that you are you, that you are trying to log in to the openid.net wiki that asked about you, and try and make sure that no one can snoop the transaction and steal your identity.
To verify who you are, the someOpenIDprovider.com server can ask you to log in to someOpenIDprovider.com itself, or check for a cookie to see if you have already done so in your current browser session. It then needs to make sure you know which site you are trying to log in to, so it will ask you about the openid.net wiki’s referring page.
If you authenticate yourself correctly and confirm that you are indeed logging in to the openid.net wiki, the server will direct you back to the wiki (to a “success! you are now logged in” page) and send a separate confirmation message directly to the wiki. The redirect for you and the confirmation message both have a one-time session key and a cryptographic signature, and because they are delivered separately the wiki can compare them and determine whether the entire transaction was legit.
But wait, there’s more
At this point, the OpenID authentication is done. But if it is your first visit to the openid.net wiki, you will find several more steps you need to complete before your wiki user account is set up. This is because OpenID replaces only the sign-on process; every other aspect of account management is left up to the site in question, including your display name, your contact info, and all of your preferences. Similarly, when a site where you already have a user account adds OpenID support, the change should have no impact on the rest of your account settings, but ultimately it is at the site maintainers’ discretion. That is an important distinction to remember: the only thing OpenID replaces is the sign-on step.
That said, there are likely to be a lot of OpenID-capable sites that will allow you to use your OpenID URL as your username simply because it makes for one less thing to try to remember, and it guarantees uniqueness. Of course, some sites might force you to use your OpenID URL as your username, in which case you might find the stuffy yourname.someOpenIDprovider.com to be an aesthetically inadequate handle.
Fortunately you can use any URL as an OpenID through a process called delegation. All you have to do is add some HTML tags to the page that you want to use as your OpenID URL that point back to the bland someOpenIDprovider.com site. You need the <link rel=”openid.server” href=”http://someOpenIDprovider.com/server” /> tag mentioned above, and a <link rel=”openid.delegate” href=”http://yourname.someOpenIDprovider.com/” /> that points to the “official” identity URL — both go inside the document’s HEAD section.
Couldn’t be easier, could it? The process outlined above is obviously not technical documentation; if you want to do further reading, the openid.net wiki links to guides written at all different levels of complexity. I have only described the most basic handshaking sequence. There are multiple variations to account for things like persistent connections and stateful sessions, which can be important if you run an OpenID-enabled public site.
What OpenID is not
There are other problems common to all public Web forums that OpenID doesn’t attempt to address. Take blog comment spam, for example. Putting a OpenID login form on your blog does not prevent spammers or spambots from generating scores of OpenID accounts and using them to flood your posts with comment spam. Instead of phony email addresses attached to those accounts, they will have OpenID identities coming from some OpenID server you’ve never heard of. As is the case with email relays, spam prevention will require human beings to observe which OpenID servers are trustworthy and which need to be blacklisted.
Or if you stumble across slanderous comments about yourself on someone else’s blog, the mere presence of an OpenID login button does not prove that the backstabbing words above your neighbor’s signature are genuine. The authenticity of a message has nothing to do with OpenID. The whole site could be faked; only a cryptographic signature from a system like OpenPGP can prove or disprove the validity or integrity of a message.
The more people who understand what OpenID is for, the faster it will spread — and we desperately need it. It is getting to the point nowadays that for every piece of hardware or software I buy, I end up having to create yet another account on the seller’s discussion forum just to ask a question about it. OpenID won’t prevent me from having to sign up at vendors’ forums, but the more Web sites, blogs, and public forums that accept OpenID, the fewer passwords I will need to manage.
