OpenID
Distributed Authentication Framework
March 27, 2009
Introduction
OpenID is a decentralized framework for user authentication and access control. It was created to solve the problem of how a user can manage multiple identities at many different web sites. The traditional solution is to create a separate account with each site, along with a user name and password that will be managed by that specific web site.
With OpenID, users can access different services (sites) using the same digital identity. It replaces the traditional login/password per site scheme and allows an OpenID Identity Provider to manage and authenticate your identity instead of leaving the task to each individual site. The OpenID framework itself does not provide any specific form of authentication – that's up to the OpenID provider.
Because the user remains in control via the OpenID provider, he can choose what information gets presented to a specific web site or application that is requesting authentication.
OpenID has become popular quite quickly. Since its beginnings in 2005, according to wikipedia, about 27,000 sites have integrated OpenID and there are over 500 million OpenIDs on the Internet.
How it works
Under OpenID, your authentication credentials (typically a password associated with your login name) are stored at an OpenID provider, such as Verisign Labs' Personal Identity Portal. Organizations such as AOL, BBC, Google (Blogger), IBM, Microsoft, MySpace, Orange, PayPal, VeriSign, Yandex, Ustream, Wordpress, and Yahoo! (Flickr) act as OpenID providers. Users can choose an OpenID provider that best meets their needs. The web sites that you access will never see your password. Instead, to log in to these sites, you will give them your identity URL, such as pxk.pip.verisignlabs.com, which identifies both the provider and your login name.
There are two modes of operation, called smart mode and dumb mode. The only difference is that in smart mode the site (relying party) pre-establishes and caches a shared secret key with the Identity Provider. It will be able to use the key to verify that the assertion data provided by the Identity Provider has not been tampered. With dumb mode, the site will have to connect to the Identity Provider and validate the user's credentials.
Step 1. Create an ID with an OpenID provider
The first step in using OpenID is to register with an OpenID provider (such as pip.verisignlabs.com and create an account. This will set up the user's name and password with the provider. Optionally, the user may be allowed to choose other authentication methods, depending on the provider.
Step 2. Visit a service (web site)
Now the user visits an OpenID-enabled web site, known as the relying party. Instead of asking for a user name and password, the site requests an OpenID identifier. The user types in his identifier (e.g., pxk.pip.verisignlabs.com) and submits the form.
The web server now knows that it needs to contact that user's OpenID Identity Provider, pip.verisignlabs.com, to authenticate the user. It will convert the OpenID identifier that the user entered into a URL and redirect the user's browser to the provider's web site.
What happens behind the scenes is that the web site converts the identifier to a URL and fetches the page to find the actual URL of the identity provider.
In smart mode, the relying party (site) may send an association request to the Identity Provider and exchange a shared secret key. It will cache this key.
Step 3. Authenticate with the Identity Provider
Now that the web server (relying party) redirected the authentication request to the Identity Provider, the user is at the OpenID provider's authentication page. The provider will now typically ask the user for a password or an InfoCard (Microsoft Windows CardSpace). It will offer the user a choice of whether to authenticate forever, for a limited time, or for one time. Finally, it asks the user whether to trust the relying party web site.
Step 4. Return to the service
If the user authenticates successfully and accepts the request from the Identity Provider, the browser is then sent a redirect to a return page on the relying party's web site. The redirect contains the user's credentials (assertion) with a digital signature by the Identity Provider.
Step 5. Service validates the user's login
The relying party now needs needs to check the validity of the user's identity what was returned from the user's browser via the redirect from the Identity Provider.
In smart mode, the site already established and cached a shared sectret key. It uses this key to decode the signature in the message, thus validating that it has not been tampered.
In dumb mode, the site establishes a secure session with the Identity Provider (preferably via SSL) and requests authentication information about the user to compare it with the assertion that was received via the browser redirect. If they match then the site is convinced that they user has successfully authenticated with the Identity Provider.
Once the OpenID identifier has been verified, the authentication is considered successful and the user is logged in.
Transparent login
An OpenID site may not even prompt the user for a login or the Identity Provider may not have to interact with the user if browser sessions and cookies are used. If the relying party has already cached the shared secret key for communicating with the Identity Provider and knows a user login (either via the user typing it or via a cookie), it can send a redirect to take the user's browser to the Identity Provider. The Identity Provider can then directly send a redirect back to the relying party with the digitally-signed assertion information. Using the shared key, the relying party can validate this information.
