OpenID - The future of logging in?

Dj Walker-Morgan

Have you noticed how the classic "log in with your user name and password" screen on many web sites now have an option to "log in with OpenID"? OpenID has established itself as the new way to make logging in easier. We'll look at how OpenID works, for users who want to log in using OpenID and for developers who want to use OpenID in their log in screens. We'll also look at how it isn't working to give everyone a better way to log in.

Why OpenID?

When a user has an account on a website, to get access to it they have to proffer their username and password, and the more accounts users have, the more username and password pairs they have to remember. Users will tend to use the same username and password around all the sites they use, and so the user becomes reliant on the security of each and every website they have an account with. On top of that, if the user loses their password, they need to change the password on every account they have.

To make life simpler, the idea of Single Sign On, SSO, was created. In an SSO enabled internet, rather than login with a new user name and password, a user would present a token of their digital identity. The website would then pass their request to log in to another service which would check the digital identity, requesting a password if necessary from the user, and tell the original website whether it could vouch for the user being who they said they were. The original website could then log the user in or throw them out.

The problem with the first wave of SSO systems was that they required the user to sign up with each of these identity providers, as some websites used one identity provider while others used another. And so Single Sign On on the internet became fractured, and as Web 2.0 arrived, developers ignored it, preferring to manage their own authentication.

The creation of OpenID

Back in 2005, at LiveJournal, Brad Fitzpatrick had an idea on how to fix this. The first problem was the hard wiring to identity providers. Rather than using a single digital identity provider, the idea was to allow the user to say which identity provider to use to confirm the users identity. This would lead though, to creating a two part identity, the provider to use and the identity for that provider, which in turn could be a username or email address. The solution was simple; make it a web address, a URL. URLs are by definition, Unique Resource Locators, and the user's identity should be unique and available as a resource for authentication.

Fitzpatrick turned this idea into OpenID. Built around a set of open standards, it defines the protocol that takes place between a website that wants to accept OpenIDs, called a relying party, and a website that wants to act as an identity provider of OpenIDs, called a server agent.

An OpenID logs in

Let's look at a typical interaction between a user, a relying party and a server agent to see what happens behind the scenes. We'll start by assuming we already have an OpenID set up with an identity provider; let's say it is http://openid.example.org/fred for a user named Fred. Fred goes to a website that supports OpenID and is asked for his OpenID, and he enters that URL. The website takes the URL and gets a document from the location to which it points. The website doesn't need to make decisions about how to authenticate as this document contains another address, this time where to send Fred's browser to continue the authentication process.

Fred is now presented with a chance to authenticate on the site of his OpenID identity provider's server agent, usually by using a password, if that is, he hasn't already authenticated. Once authenticated, Fred is asked if he is happy for the site that has asked for authentication to be allowed to identify him. If Fred says no, then Fred's browser is redirected back to the originating website with a message that authentication has failed. If Fred says yes, he is returned to the originating website, along with identify credentials from the identity provider. Finally, the website has to check it trusts the reply, and if it does, it continues the session with the authenticated user. The process can involve the exchange of secret keys between the relying party and the server agent to help prove the reliability of the authentication reply. This identity handshake, where the user never gives their password to any other site but their identity provider and where a site accepting OpenID relies on authentication through another site, creates a simple framework for OpenID developers.

Who provides OpenID?

Big OpenID providers like Google, Yahoo, Flickr and LiveJournal already had authentication mechanisms in place for users logging in, so supporting OpenID as an identity provider was simply a matter of creating a URL scheme to give each user their own OpenID URL and responding to OpenID requests from relying parties and using those existing mechanisms. There are also dedicated identity providers like MyOpenID, run by JanRain, who specialise in OpenID tools, and others who are looking at better authentication mechanisms such as biometrics or smart cards.

If an OpenID user doesn't like the idea of using a third party URL as their identity, OpenID allows them to "personalise" their ID. By placing two <link> tags which point to their OpenID provider's identity into a HTML page served from a URL, they can use that URL as their OpenID identity. A relying party will go to that URL, find the tags and redirect itself to the actual OpenID provider. You can read about this delegation process on the OpenID web site.

For sites that want to use OpenID as an authentication system, there are already a number of libraries aimed at making the implementation easier. For example, Ruby developers could use the JanRain OpenID libraries directly or use the Restful OpenID Authentication plugin, which assembles all the components for authentication. If you have an existing account and authentication system, you can bring in OpenID along side that by creating a map of OpenID identities to local accounts, rather than doing a one-to-one mapping. This will allow for users to associate more than one OpenID with an account, and for users with existing accounts to move to OpenID.

The problem of OpenID asymmetry

One of the issues with OpenID is the asymmetry between identity providers and relying parties; although Google and Yahoo act as OpenID providers, neither of them will accept OpenID from users as log in credentials, except for some limited services. Being an identity provider is easy for them, but they have yet to fully adopt OpenID, leading some to suggest that the big OpenID providers were exploiting it by using it as leverage to "own" users. There is a lot for the big players to gain from providing OpenID to their users; if a user uses their Google OpenID, for example, to log in to a number of sites, Google will end up with a list of all the sites the user has logged into. This is quite legitimate; they have to remember your past login preferences, but it also gives them valuable data which could be used in targeting advertising content. The same applies for all the OpenID identity providers, but at least with the smaller providers, there's no business model to consume your login activity. This isn't to say that any Identity Provider actually does this, but it does show that you do need to trust your identity provider.

Consuming OpenID is a bigger challenge to Google, Yahoo and the other big identity providers; they can easily offer reasons why they currently can't rely on OpenID for their needs. Some hope that the OpenID foundation, which boasts a membership that includes Google, IBM, Microsoft, Verisign and Yahoo, can convince these members to accept OpenID, or at least allow users to associate an OpenID from another OpenID provider with their account.

Despite these issues, OpenID is one of the first Single Sign On systems that is easy to use, open enough to prevent any one party taking control and widely supported.