An introduction to OpenID

Recently I've been working on extending an existing site with OpenID. In the coming weeks I'll be going into details of OpenID in different ways. This week I'm going to give an overview of OpenID and the areas of the specification that can be improved for readability. In the following weeks I'll be addressing:

• A comparison of OpenID authentication providers.
• A description of my experience implementing OpenID, including a comparison of libraries.
• Outstanding issues with OpenID (security).
• Where's OpenID going to.

In this first post I'm not going to give a full detailed explanation of OpenID. There are many sources that provide quite a good description. Here's a list of what I am not going to describe, but can be a good starting point to learn about OpenID:

• Wikipedia has a good definition:
  
  

  "OpenID is a decentralized single sign-on system. Using OpenID-enabled sites,
  web users do not need to remember traditional authentication tokens such as
  username and password. Instead, they only need to be previously registered on a website with an OpenID "identity provider", sometimes called an i-broker. Since OpenID is decentralized, any website can employ OpenID software as a way for users to sign in; OpenID solves the problem without relying on any centralized website to confirm digital identity."

• A good starting point is of course the home of the OpenID specification. You'll see there that the current version is 1.1 and 2.0 is in draft.
• The difference between SAML and OpenID. Here's a good starting point.
• Examples of major websites supporting OpenID are: WordPress, LiveJournal, AOL and Digg.

I'd like to focus on a few elements that I found not very well explained on the OpenID website. For example, not very well described (to me :-) is how the delegation of your OpenID provider works. It took me quite some investigation and looking at other sites to figure out how it exactly works. What is comes down to is that OpenID is all about you being able to prove that you are owner of a URL. And a URL is basically just a webpage. The idea is that normally that page contains a <link> tag in its HTML, within the tag, providing where your OpenID provider/authenticator is located. Say you have an OpenID account named 'mytest' at myopenid.com. Than you can actually go to the URL mytest.myopenid.com with your browser. When you look at the HTML you'll find this:

<link rel="openid.server" href="http://www.myopenid.com/server" />

Use <link rel="openid2.provider" href="http://www.myopenid.com/server" /> for version 2.0 providers

This tells you which OpenID server should be used to authenticate the URL mytest.myopenid.com. There are two major disadvantages to this:

• Maybe you want to use a different URL, not with "myopenid.com" in it. E.g. mytest.com.
• What if myopenid.com goes out of business? You can't login anymore to *any* of the sites you registered with that OpenID!

The solution for this is to use delegation. In that case the <link> tag in the page returned when going to the URL mytest.com would look like this:

<link rel="openid.server" href="http://www.myopenid.com/server" />

<link rel="openid.delegate" href="http://mytest.myopenid.com/" />

Note the additional "openid.delegate" <link> tag. In the above example it points to the myopenid.com OpenID provider and uses mytest.myopenid.com for authentication: authentication of mytest.com is delegated to myopenid.com. If ever myopenid.com is not available anymore, you can just create an account at another OpenID provider and put that in the href attribute in the above <link> tag instead of mytest.myopenid.com. This is using the essential OpenID principle that you actually own the URL. Since you can change the OpenID provider that was contained in the URL, you must be owner of the URL!

Another thing to realize is that the OpenID protocol has no failover requirements defined for OpenID providers. You as owner of the URL will have to arrange that and make sure that you can still authenticate your URL in case the OpenID provider is down/out of business. The only way you can do that is via via delegation. I find this one of the lesser things of OpenID. Delegation is quite hard to understand for "average" Internet users, thus putting the responsibility of "failover" in their (own) hands can cause quite some suprises for them.

The third area where I found the OpenID home and this other good source of OpenID information not well done is giving a good visual diagram of the OpenID protocol. Much clearer is this very detailed description of the protocol flow in OpenID 2.0, including a nice sequence diagram, in this ServerSide article. It is already discussion version 2.0, but it also applies to 1.x except the XRI/XRDS parts. Below that diagram is shown for easy reference: