At the Forge

Thank goodness for Firefox. Yes, it's a great browser. Yes, it has all sorts of wonderful plugins that let me do everything from debugging my Web applications to checking the weather forecast. And, the fact that it works across multiple platforms makes it even better.

But, as Web-based applications become an increasingly integral part of my life, I've grown dependent on Firefox's ability to remember my passwords. It might be silly, or even a bit pathetic, but there is no way I can remember all the different passwords I've created over the years. This is especially true for sites where I've changed my password on occasion, either because my current password expired or because I decided to change it.

This also means that when I use a different browser, or even a different computer, I'm often at a total loss. Sure, I remember some of my passwords, but there is no easy way for me to keep track of all of them without writing them down somewhere. So, I do the digital equivalent—storing them in my browser—and make sure I have my laptop with me wherever I go.

Juggling multiple passwords isn't new, of course. Even before the growth of Web applications, people were logging in to different computers, networks, e-mail accounts, database systems and so on. A number of companies made quite a bit of money from “single sign-on”, offering back-end solutions that allowed people to log in to a single computer, providing them with access to many different ones.

But, although the problem might not be new, its scale is unprecedented. We no longer are worried about several hundreds or thousands of individuals keeping track of a dozen passwords, with access to an IT support department. Rather, we now have to worry about many millions of people, each of whom has dozens of passwords and little or no technical support for any of them.

Moreover, each Web site has its own particular needs, not to mention its own unique user interface. And, to top it off, the world is quite different from a corporation; you can't impose a standard solution from above. Rather, there must be a way to introduce competition into the equation, such that individuals can choose their own single sign-on provider.

Over the years, a number of companies have tried to enter this space for Internet applications. Perhaps the most famous (or infamous) was Microsoft's .NET Passport (now known as Windows Live ID), which was launched with great fanfare—and quickly attracted a great deal of negative attention related to privacy concerns. Even if Microsoft's product was technically excellent (and I'm not knowledgeable enough to judge it), people did not want to be told with whom they must entrust private and sensitive data.

An increasingly popular solution to this problem is OpenID. OpenID is not necessarily a new technology; it has existed in some form or another for several years already. However, it rapidly is picking up steam—so much that right before I wrote these words in February 2008, we saw Microsoft, Google, IBM, VeriSign and Yahoo embrace OpenID.

Now, it's true that the number of sites supporting OpenID is currently small—numbering about 8,000 at the time of this writing. However, the number is growing rapidly, and I expect the pace will pick up as the aforementioned Internet giants begin to get involved.

What if you're smaller than Google or Microsoft? Is OpenID worth adding to your site? Is it relatively easy? The answer to both questions, I'm happy to say, is yes.

This month, I discuss the user side of OpenID—how you register for an OpenID and how you manage it. I also explain how the OpenID specification takes into account the fact that you might eventually need to change providers.

The term OpenID refers both to a person's unique identifier and to the standard describing all the technology around that identifier. To create an OpenID, you must register with an OpenID provider. Once you have registered your OpenID, it is the provider that authenticates you for every OpenID-enabled application you use. In other words, the OpenID provider is responsible for checking your identity, which normally means confirming that the user name and password you enter are acceptable.

Thus, logging in to a site with OpenID means the following happens:

Notice there are a few important differences here between OpenID and a “standard” login system. First, users authenticate against a different site from the one they are trying to use. This is similar to making a purchase via Google Checkout or PayPal, both of which require that users authenticate themselves and authorize the purchase amount on their own sites, rather than on the site belonging to the on-line store.

Some critics of OpenID say that users may be surprised or confused by the switch from one site to another, but I think Google Checkout and PayPal have demonstrated that a reasonable number of people are not put off by switching back and forth. Moreover, I have read that Firefox 3 will include some integrated OpenID support, which might remove some of the need to switch sites—or at least make it appear more integrated. However, I've been using the beta of Firefox 3 for several months and have yet to experience such integration.

And, although I use the term Web application, there is no requirement that OpenID be used only for Web-based applications. I expect that as OpenID takes hold, a large number of Internet-based applications, obviously including those that run on the Web, will use OpenID. However, there's no reason why non-Web applications and services couldn't use OpenID as well. I even can imagine a day when you might use OpenID to enter your house or confirm your identity to your burglar-alarm company. In the world of OpenID, end-user applications are known as consumers, just as the OpenID authentication systems are known as providers.

Most OpenID providers authenticate users with a user name and password. Over time, we can expect them to go in other directions as well—for example, using biometric authentication systems. And, although OpenID providers currently offer their services for free, it's not hard to imagine a time in which some companies will charge for OpenID services, while others will support themselves via advertising. Because users can switch OpenID providers at any time, and because users have a choice as to which one they will use, we can expect both competition and ingenuity to be the rule.

One company, Vidoop, has a particularly interesting authentication mechanism, in which users select a pattern of images as their “password”. Each time a user wants to authenticate, a set of images—including those that the user has selected—appears on a 3x3 grid, with each image in a randomly selected location and a random letter placed next to it. This effectively creates a one-time password, which users enter by typing the letters associated with the ordered set of images they originally chose.

Finally, I should note that you can create and use as many OpenIDs as you like, just as you would normally create as many user names as you like on a Web site. Some people do this to separate their work ID from their personal ID, or just because they prefer not to put all of their eggs in one authentication basket. Regardless, OpenID allows you to do this—although it is ironic that a single sign-on solution would spur people to create multiple identities.

With all the background information out of the way, let's create and use an OpenID. An OpenID is nothing more than a URL, typically written as http://USERNAME.PROVIDER.com. For example, my OpenID is http://reuvenmlerner.myopenid.com.

Notice that I can share this URL publicly; there is no reason for me to keep it secret. MyOpenID.com is just one of several OpenID providers. Indeed, many people already have an OpenID, even if they don't realize it. For example, if you have a blog at LiveJournal, that URL can be used as your OpenID.

To sign up for an OpenID, simply go to the home page of your provider. For example, go to the MyOpenID.com home page and click on “sign up for an OpenID”. That takes you to https://www.myopenid.com/signup, which asks you to enter a user name (it must be unique) and a password. You also can provide an e-mail address, which is optional, but doing so allows you to recover your password if you ever forget it. Finally, MyOpenID.com uses a captcha to ensure that a person, rather than a program, is signing up for the account.

Once you have signed up for an OpenID, you can use it to log in to a Web site that supports it. Typically, logging in to a Web site requires that you enter both a user name and password. But, if you use OpenID, you enter in neither of these to the Web application's login screen. Instead, you enter only the URL of your OpenID, including the http prefix that we so often ignore nowadays.

For example, I can go to www.wikihow.com, a site that lets anyone create a how-to manual. I click on “create an account or log in” at the top of the page, which brings me to a login screen. The resulting screen tells me I can log in using OpenID, if I want, by going to www.wikihow.com/Special:OpenIDLogin. (In other words, wikiHow has two separate login pages: one for regular users with a user name/password combination and another for OpenID users, who enter only their OpenID URL.) Finally, I enter http://reuvenmlerner.myopenid.com into the text field.

Because I had logged in to OpenID earlier, I wasn't asked to provide my password. However, this is the first time I've tried to log in to wikiHow with OpenID. Thus, MyOpenID.com must verify that I am willing to share information with wikiHow. I click on the allow forever button, which means whenever I'm logged in to MyOpenID.com, it should share information with wikiHow. After clicking this button, I am redirected back to www.wikihow.com, where I am logged in and identified by my first name.

This system works quite well in my experience, and you quickly become used to the back and forth authentication process. However, major problems remain. What happens if MyOpenID.com goes out of business? What if its database is compromised? What if it turns out to be highly unethical and is using people's IDs? What if I find a provider whose Web site is more attractive to me?

I always can switch to a different provider, of course. But, that effectively means having a new and different user name on a site. On a social-networking site, this obviously would be disastrous, as I would need to reconnect from my new account to each of the people in my old account.

The solution to this is quite clever. Instead of giving people the OpenID I mentioned above, I instead give them an OpenID on a Web site that I control, whose URL is unlikely ever to change. For example, I can give an OpenID of http://reuven.lerner.co.il.

I know that the lerner.co.il domain will remain mine forever. Thus, I can be reasonably sure that this URL also will be in my possession for a long time. Moreover, I control the contents of the home page. That page may contain any HTML content I want. But, it also should contain the following two <link> tags in the <head> section:

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

We already saw how I can log in to wikiHow by giving my OpenID at MyOpenID.com. But, with the above lines in place, I also can log in to wikiHow by entering http://reuven.lerner.co.il.

This tells wikiHow to retrieve the home page from my personal Web site. It uses the first <link> tag to know which server to use and the second <link> tag to know which user name and ID to authenticate. Everything then continues as usual. I authenticate myself as necessary against MyOpenID.com, which then redirects me back to wikiHow.

The beauty of this redirection system is that if I decide against using MyOpenID for any reason in the future, I simply change the <link> tags in index.html. wikiHow and all other sites will follow whatever reuven.lerner.co.il points to, whether it's MyOpenID.com, Vidoop.com or something else. In this way, I ensure that my OpenID always is associated with the provider who offers me the best combination of security and usability for my purposes.

Unfortunately, things don't always go smoothly. For example, when I registered with wikiHow, it got my nickname (Reuven) from MyOpenID.com. When I try to log in with my new, redirected OpenID, wikiHow thinks it's dealing with a new user—one whose requested nickname clashes with that of an existing user. So, the key is to set up and use the redirecting URL early on, and not switch to it after you already have used OpenID for some time.

There are other problems as well. For example, I currently juggle two different sets of identities on-line, as some companies want to deal only with US citizens living in the United States. And, although I'm currently back home in Modi'in, Israel, I continue to have a US phone number (through Skype), a mailing address (at my parents' house), and a US bank account and credit card. So, I need two separate identities: one with my Israeli information and another with my US information.

Fortunately, OpenID 2.0 supports both the export of information to the consumer application and also the use of multiple personas. Each persona can have a separate name, nickname, image and location, and I can choose which persona is associated with each consumer, under the umbrella of the same OpenID.

OpenID is an increasingly important standard that seems poised to have a central role in future Web and Internet-connected applications. Using OpenID is not terribly complicated for end users, and it supposedly is going to be integrated into Firefox in the near future.

Next month, we will look at OpenID from the perspective of a Web site that requires users to register. How can you, as a Web developer, support OpenID on your site? We will see that with a bit of work, and some support from open-source libraries, we can support OpenID in our Web applications.