OpenID

What is OpenID?
OpenID eliminates the need for multiple usernames across different websites, simplifying your online experience.
You get to choose the OpenID Provider that best meets your needs and most importantly that you trust. At the same time, your OpenID can stay with you, no matter which Provider you move to. And best of all, the OpenID technology is not proprietary and is completely free.
For businesses, this means a lower cost of password and account management, while drawing new web traffic. OpenID lowers user frustration by letting users have control of their login.
For geeks, OpenID is an open, decentralized, free framework for user-centric digital identity. OpenID takes advantage of already existing internet technology (URI, HTTP, SSL, Diffie-Hellman) and realizes that people are already creating identities for themselves whether it be at their blog, photostream, profile page, etc. With OpenID you can easily transform one of these existing URIs into an account which can be used at sites which support OpenID logins.
OpenID is still in the adoption phase and is becoming more and more popular, as large organizations like AOL, Microsoft, Sun, Novell, etc. begin to accept and provide OpenIDs. Today it is estimated that there are over 160-million OpenID enabled URIs with nearly ten-thousand sites supporting OpenID logins.

OpenID is an open protocol that enables a person to use a URL as an identity and use the same identity (the URL) at multiple web sites that support OpenID. Web- enabled applications can use the identity URL for authentication, authorization, and other purposes. It is a relatively new concept which puts the control of the identity into the hands of its owner, the end user. The owner of the identity can decide, and has control over, which information should be presented to an application or web site for authentication purpose.
Among other things, OpenID enables owners to:
· Login to web-enabled applications and web sites without ever entering any username and password information.
· Enable web sites to request information from a user; and empowering the user to choose which information is to be sent to a web site during authentication/authorization process.
· Chose which sets of information (also known as profiles or cards) to be sent to different web sites, based upon need and risk level.
· Allows implementation of graded and risk-based authorization.
· Implement an alternate to single sign on (SSO) for multiple applications within an organization.
· Implement an alternate mechanism for cross-company authentication (CCA) for affiliates and business partners.
· Integrate applications into the OpenID system using a simple and elegant mechanism.
· Lower cost of implementation and maintenance of an identity management solution.

Who Owns or Controls OpenID?
OpenID has arisen from the open source community to solve the problems that could not be easily solved by other existing technologies. OpenID is a lightweight method of identifying individuals that uses the same technology framework that is used to identify websites. As such, OpenID is not owned by anyone, nor should it be. Today, anyone can choose to be an OpenID user or an OpenID Provider for free without having to register or be approved by any organization.
The OpenID Foundation was formed to assist the open source model by providing a legal entity to be the steward for the community by providing needed infrastructure and generally helping to promote and support expanded adoption of OpenID.
As Brad Fitzpatrick (the father of OpenID) said, “Nobody should own this. Nobody’s planning on making any money from this. The goal is to release every part of this under the most liberal licenses possible, so there’s no money or licensing or registering required to play. It benefits the community as a whole if something like this exists, and we’re all a part of the community.”


Terminology

1. Identifier : URI or XRI
2. Replying party (RP, Consumer)
3. openID provider (Identity provider, openID server)

There are three major components in any OpenID system: Consumer, Identity Provider, and User Agent. These components interact with each other during the authentication process. Roles for these components are explained next.

1. The Consumer, which is the web site where you are trying to login, interacts with the Identity Provider and the User Agent (the web browser). An End User will try to login to the Consumer web sites using OpenID. During the authentication process, the Consumer will send some messages to the Identity Provider directly as well as via User Agent with the help of HTTP redirect messages.

2. The Identity Provider is the OpenID server that holds an End User’s
credentials. The Identity Provider will validate the ownership of an identity URL to the Consumer using two basic mechanisms which we shall discuss later in this chapter.

3. An End User will interact with the Consumer and Identity Provider using the User Agent. The User Agent is your web browser.

During the authentication process, the browser acts as the middle man between the Identity Provider and the Consumer web site for some messages. Typically, a Consumer will interact with the web browser as well as the Identity Provider during authentication process. However in some cases, the Consumer may use cached keys to authenticate a user without any direct communication with the Identity Provider.

 

There are two basic communications methods among different entities in an OpenID system:

1. Direct Communication
2. Indirect Communication.

In the Direct Communication mechanism, two entities directly talk to each other using the HTTP protocol. The HTTP POST method is used for direct communication.

With the Indirect Communications, two entities talk to each other via a third entity. This third entity is typically the web browser. Indirect communication may happen via HTTP Redirect or via HTML Form redirection.

OpenID has two major modes of operation: the Dumb mode and the Smart mode. These modes are based upon how intelligent the Consumer is. In Dumb mode, as the name implies, the consumer is not that smart and has to perform few additional steps every time a user logs in. In Smart mode, the Consumer keeps state information and caches shared keys for future use.

Dumb Mode Communications Flow

1. You visit the Consumer web site where you want to login.
2. The web site presents a web page where you enter your identity URL. Typically, you will enter your Identity URL (for ex http://myvikas.myopenid.com) and click on Login button. Different web sites may have different types of web pages but the process will remain the same.
3. The Consumer web site will clean up the Identifier URL and fetch the information from its current URL location. . In OpenID specification version 2, another XML protocol, known as Yadis, can also be used at this stage for service discovery.
4. After fetching the page, the Consumer will then parse it and determine the location of Identity Provider (OpenID Server). This parsing process is also called discovery. After parsing, the Consumer will then redirect the web browser to the Identity Provider to obtain the assertion information. This happens using the HTTP GET method. Optionally, the consumer may establish a connection with the identity provider at this point and exchange a shared secret for further communication. This is shown with a dotted line in Figure and marked as step 4a.
5. If the end user is not already logged into to Identity Provider, the Identity Provider may ask the End User to login. However, it should be noted that this part is outside the OpenID specifications and it is left to the Identity Provider to decide how to authenticate the End User. In some circumstances, if you have already logged into the Identity Provider web site, this part may be skipped altogether.
6. The Identity Provider website will return the assertion information with its signature to the Consumer via browser redirect. This assertion will represent either an authentication success or failure. The HTTP GET method is used in this step as well. Note that this is the Indirect Communication between Identity Provider and the Consumer.
7. During successful assertion, the Consumer will establish a direct connection with the Identity Provider, preferably over a secure SSL session. It will request the authentication information directly from the Identity Provider and compare it with the assertion information it received via User Agent (web browser). This is to double check the validity of the assertion in case a User Agent (or a malicious attacker) is trying to cheat.
8. If there is a match in the previous step, the End User will login to the website. Otherwise the login will fail.

Smart mode communication is almost same except a change in point-7. It is :
After a successful assertion, the Consumer verifies the assertion using the cached shared key. If there is a match in the previous step, the End User will login to the web site. Otherwise login will fail.

Detailed diagram of openID protocol:

There are a lots  of terms like XRDS, yadis described in this diagram. I will expore these terms soon in deeper detail.