penID is a service, framework, and protocol that is revolutionizing the realm of user authentication and identity services. Started in 2004 by Brad Fitzpatrick, OpenID is now a mature framework supported by major Internet organizations such as AOL, Google, IBM, Microsoft, VeriSign, and Yahoo. It offers a distributed, reliable, and open way for web sites to authenticate their users and saves web developers from the need to write yet another piece of authentication code.

This article describes what OpenID is and how it can benefit your web site development. It provides an example by demonstrating OpenID integration with the Ruby on Rails 2.0 framework.

One Web-Wide Identity for the User
Authentication in web applications is the process of verifying someone's identity and confirming that the user accessing the application really is who he claims to be. The most popular method of authentication is using a username and password: the username declares the user's identity, while the password represents the verification token that ensures that only its holder can claim the identity of the associated username. The vast majority of web sites that need to verify their users' identities adopt this form of authentication, each one implementing its own login or verification component.

Unfortunately, the username and password combination leads to extreme fragmentation of user credentials: users end up having tens of usernames and passwords for multiple sites (bank account, e-mail, blog, company web site, etc.). OpenID aims to solve this fragmentation once and for all. As stated on its web site, OpenID offers a way to define "a single digital identity across the Internet," eliminating the need for multiple usernames across different web sites. OpenID keeps a user's credentials in a single place, where other web sites can query them whenever they need to verify that user's identity.

The OpenID service encompasses a few different entities that interact with each other:

• An OpenID provider stores user credentials and exposes a standard API that other web sites can query to authenticate users. Popular free providers are myOpenID and VeriSign.
• A relying party is a web site that wants to verify a user's identity.
• The end user is the person trying to authenticate him- or herself on the web site.

In the OpenID world, a user is uniquely identified by an OpenID identifier, which generally is a plain URL (think of it as the person's unique username). The OpenID identifier usually points to the provider that is storing the user's credentials. An example is yourname.myopenid.com.

Figure 1 and Figure 2 illustrate the differences between a traditional authentication scheme and the OpenID one, respectively.

Figure 1. A Traditional Authentication Scheme: The user has different credentials for each web site.

Figure 2. The OpenID Authentication Scheme: The user has only one set of credentials, shared among different web sites.

As the figures illustrate, the OpenID authentication flow is a bit different from traditional database-based authentication. OpenID authentication can be summarized in the following steps:

Figure 3. The OpenID Authentication Flow: The user has different credentials for each web site.

1. A user wants to authenticate himself on a web site.
2. The user provides his OpenID identifier to the web site.
3. The web site translates the identifier into a canonical URL (such as http://yourname.myopenid.com).
4. The web site redirects the browser to the generated URL, where the user can authenticate himself against the OpenID provider.
5. The OpenID provider authenticates the user, either with a traditional method (username and password) or with more advanced techniques, such as certificate exchange.
6. If successful, the OpenID provider redirects the browser back to the originating web site, along with the verified user credentials.
7. The web site uses the credentials to identify the user and forwards him to its services.
8. If unsuccessful, the OpenID provider redirects the browser back to the originating web site, along with an error key that the web site can use to handle the situation.

To guarantee security and prevent identity spoofing, the web site and the OpenID provider perform some extra steps. However, web developers who use the OpenID client library don't need to get into these details, because the library handles them all transparently (the OpenID client library is used for the example in the section to follow).

The latest version of the OpenID specifications (Version 2.0) allows for further complexity by introducing the concept of provider discovery. You don't need to delve into these details to be able to integrate your web site properly with OpenID. Figure 3 shows a schematic of the above sequence.