A look at OpenID

The OpenID project is an effort to produce a decentralized, open, user-centric identity management framework. The main benefit for users will be a 'single sign on' to websites that support it. The project provides open source libraries for both websites requiring authentication (relying parties) and for the servers that provide the authentication (identity providers, IdPs). One of the main goals is to allow anyone to run a server that authenticates their own or others' identities and avoid the centralized model of other identity frameworks.

At its core, OpenID allows a user to associate a URL with his or her identity; a server can then authenticate that the user is the owner of that URL. Giving users control of their own identity makes OpenID a user-centric identity management system. To use OpenID authentication, the username is the URL and the password is stored on the identity provider. Thus, the same password is used to authenticate multiple accounts on various websites.

There are different ways to use OpenID, depending on what the user's requirements and capabilities are. In the simplest case, one can sign up for a free account at a provider like MyOpenID and it will generate a URL for you to use (the author's test account was jake.edge.myopenid.com). After that, you can submit that URL at any OpenID enabled website and authenticate it. If you have not visited the site before, you will be redirected to MyOpenID to enable that site to authenticate you. You may also need to login to MyOpenID if you have not established a session there recently. Once you have enabled authentication, you are redirected back to the original site and MyOpenID will have authenticated you. If you have a valid MyOpenID session and have previously enabled the site you are visiting, you can be authenticated behind the scenes when you provide your URL and will be able to log in without providing a password.

Another way to use a service like MyOpenID is by using a URL under your control as your identity. By putting some HTML into the HEAD section of the index document served from that URL, you can delegate the authentication to another server and gain the benefits of using your own URL without running your own OpenID server. If you do that, the URL for OpenID logins becomes the URL under your control. Over time, you could change the server that you delegate to while still retaining the identity associated with your URL. In addition, various OpenID server implementations exist for those who wish to fully control their identity and can run their own server.

OpenID implements the authentication by using (but not requiring) strong encryption on the messages that are exchanged between relying parties and identity providers (IdPs). When a user enters a URL into an OpenID login, the relying party makes a GET request to the URL and expects to find some extra OpenID specific markup in the HEAD section. It uses this markup to find the IdP and can negotiate an association between the relying party and IdP, but does not have to. The association is an agreement on cryptographic protocols to use to sign the requests and responses. A relying party can then cache that information to use when contacting that IdP for any other user that might share the server.

After that, the relying party redirects the user to the IdP which allows any IdP specific cookies to be delivered. The IdP may decide to require the user to authenticate with it, but that is outside of the scope of the OpenID specification. As described above, the IdP may also require the user to make a decision about whether to allow the relying party to authenticate them. Once that is complete, the IdP returns the user to the relying party site with an assertion about whether the authentication succeeded or failed.

The most recent OpenID specification adds some additional capabilities. A nonce (a unique identifier) value was added as an option to the success response to thwart replay attacks. Also, support for Yadis discovery was added. Yadis allows relying parties to determine what authentication protocol to use so that sites can transparently support other protocols such as LID.

From a security standpoint, there are a few different attack vectors that are described in the specification. Eavesdropping and man-in-the-middle attacks can be circumvented by using HTTPS (SSL). Unless the IdP is compromised, the identity itself is secure, though it could be spoofed on a particular site using those vectors.

OpenID simply makes the connection between a URL and an identity, it asserts that the two are associated, it does not provide any trust information about the identity. Users of OpenID will still have to prove they are not programs at registration time because nothing in the protocol prevents programs from having identities. It is a starting point, as any kind of trust system must be based on an authenticated identity. A trust layer that uses OpenID identities could provide protection against blog spam and the like. Since OpenID identities can be anonymous, this will allow for anonymous, but authenticated, users; one can verify that the identity wrote a particular message without making a connection to the real life person behind it.

There seems to be a growing number of sites that support OpenID; there is even a bounty for adding support to open source programs. Overall, it seems that OpenID provides a fairly painless route for digital identity management for both users and websites. It is probably worth a look for anyone that might be interested in such a thing.