OpenID

Anush Shetty

OpenID is an open, decentralized, free framework for user-centric digital identity. OpenID starts with the concept that anyone can identify themselves on the Internet the same way websites do-with a URI – Uniform Resource Identifier (also called a URL or web address). Since URIs are at the very core of Web architecture, they provide a solid foundation for user-centric identity.

On OpenID-enabled sites, Internet users do not need to register and manage a new account for every site before being granted access. Instead, they only need to be previously registered on a website with an OpenID "identity provider", sometimes called an i-broker. They can also link to this identity provider from another website they own and log in using that website's URI instead, allowing them to connect their identity to their website. A website which accepts sign-ins from OpenID is called a "relying party."

OpenID is increasingly gaining adoption amongst large sites since it provides an single universal login system of your choice and also makes thing much easier. Today we have organisations like LiveJournal , Microsoft, Mozilla extending their support to OpenID.
Currently OpenID does not provide its own form of authentication, so we wont be able to use it on sensitive accounts (banking, e-commerce transactions, etc.), but if an identity provider uses strong authentication, OpenID can be used for all types of transactions.

How OpenID works

A website, such as example.com, which wants to enable OpenID logins for its visitors, places a login form somewhere on the page. Unlike a typical login form, which prompts the user for a user name and password, there is only one field - for the OpenID identifier. The site may choose to display a small OpenID logo next to the field. This form is connected to an implementation of an OpenID client library.

If a user named Alice wants to log in to example.com using the OpenID identifier alice.openid-provider.org that she has registered with the identity provider openid-provider.org, she simply goes to example.com and types alice.openid-provider.org in the OpenID login box.

If the identifier is a URL, the first thing the relying party (example.com) does is transform into a canonical form, e.g., http://alice.openid-provider.org/. With OpenID 1.0, the relying party then requests the web page located at that URL and, via an HTML link tag, discovers that the provider server is, say, http://openid-provider.org/openid-auth.php. It also discovers whether or not it should use a delegated identity (see below). Starting with OpenID 1.1, the client does discovery by requesting the XRDS document (also called the Yadis document) with the content type application/xrds+xml that may be available at the target URL and is always available for a target XRI.

There are two modes in which the relying party can communicate with the identity provider:

  • checkid_immediate, which is machine-oriented and in which all communication between the two servers is done in the background, without the user's knowledge;
  • checkid_setup, in which the user communicates with the provider server directly using the very same web browser used to access the relying party site.

The second option is more popular on the Web; also, checkid_immediate can fallback to checkid_setup if the operation cannot be automated.

First, the relying party and the provider (optionally) establish a shared secret - an associate handle, which the relying party then stores. If using checkid_setup, the relying party redirects the user's web browser to the provider. In this case, Alice's browser is redirected to openid-provider.org so Alice can authenticate herself with the provider.

The method of authentication may vary, but typically, an OpenID provider asks for a password (and then possibly stores the user's session using cookies, as many websites with password-based authentication do). Alice may be prompted for her password if she was not logged in on openid-provider.org, and then asked whether she trusts, say, http://example.com/openid-return.php - the page designated by example.com as the one where the user should return after completing authentication - to receive details about her identity. If she answers positively, OpenID authentication is considered successful and the browser is redirected to the designated return page with credentials given. If Alice decides not to trust the relying party site, the browser is still redirected - however, the relying party is notified that its request was rejected, so example.com refuses to authenticate Alice in turn.

However, the login process is not over yet because at this stage, example.com cannot decide whether the credentials received really came from openid-provider.org. If they had previously established a shared secret (see above), the consumer can validate the shared secret received with the credentials against the one previously stored. Such a consumer is called stateful because it stores the shared secret between sessions. In comparison, a stateless or dumb consumer must make one more background request (check_authentication) to ensure that the data indeed came from openid-provider.org.
After Alice's identifier has been verified, she is considered logged in to example.com as alice.openid-provider.org. The site may then store the session or, if this is her first logon, prompt Alice to enter some information specific to example.com, in order to complete registration.

Terminology

A basic glossary of the terms used with OpenID:

  • consumer — An obsolete term for the relying party.
  • end user — The person who wants to assert his or her identity to a site.
  • identifier — The URL or XRI chosen by the End User as their OpenID identifier.
  • identity provider — A service provider offering the service of registering OpenID URLs or XRIs and providing OpenID authentication (and possibly other identity services).
  • relying party — The site that wants to verify the end user's identifier.
  • server or server-agent — The server that verifies the end user's identifier. This may be the end user's own server (such as their blog), or a server operated by an identity provider.
  • user-agent — The program (such as a browser) that the end user is using to access an identity provider or a relying party.

 Transforming a HTML Document Into an Identifier

In order for a user to know the Identity Provider authoritative for an Identifier, the End User must add markup to the HEAD section of the HTML document located at their URL.
To use http://example.com/ as the End User's Identifier http://openid.example.com as their Identity Provider, the following tag would be added to the HEAD section of the HTML document returned when fetching their Identifier URL.
<link rel="openid.server" href="http://openid.example.com/">

 Delegating Authentication

If the End User's host is not capable of running an Identity Provider, or the End User wishes to use one running on a different host, they will need to delegate their authentication. For example, if they want to use their website, http://www.example.com/, as their Identifier, but don't have the means, or desire, to run an Identity Provider.
If they have a LiveJournal account (say, user "exampleuser"), and know that LiveJournal provides an OpenID Identity Provider and that it'll assert that they control the Identifier http://exampleuser.livejournal.com/ they would be able to delegate their authentication to LiveJournal's Identity Provider..

So, to use www.example.com as their Identifier, but have Consumers actually verify http://exampleuser.livejournal.com/ with the Identity Provider located at http://www.livejournal.com/openid/server.bml, they'd add the following tags to the HEAD section of the HTML document returned when fetching their Identifier URL.

<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml">
<link rel="openid.delegate" href="http://exampleuser.livejournal.com/">

Now, when a Consumer sees that, it'll talk to http://www.livejournal.com/openid/server.bml and ask if the End User is exampleuser.livejournal.com, never mentioning www.example.com anywhere on the wire.
The main advantage of this is that an End User can keep their Identifier over many years, even as services come and go; they'll just keep changing who they delegate to.

Libraries

With the wide adoption of OpenID , several libraries are available today for  easier implementation of OpenID. The following libraries are available to assist with the implementation of an OpenID Identity Server and Consumer. The libraries in this section are intended to help with handling all of the details specific to OpenID and leaving you to provide the glue to integrate it into your site.

  • C#

JanRain OpenID
NerdBank ASP.NET OpenID control (uses JanRain)
ExtremeSwank OpenID Consumer (written in C# from OpenID 1.1 spec)

  • C++

http://kin.klever.net/libopkele/

  • Java

http://www.idprism.org/
NetMesh InfoGrid LID Java
OpenID4Java, with OpenID Authentication 2.0 support. Developed by Sxip
joid

  • Perl

JanRain OpenID
Net::OpenID::Server - wants Crypt::OpenSSL::DSA but doesn't have it in its dependency list (v0.10)
Net::OpenID::Consumer
NetMesh InfoGrid LID Perl
OpenID4Perl, with OpenID Authentication 2.0 support. Developed by Sxip

  • Python

JanRain OpenID

  • Ruby

JanRain OpenID library
Heraldry OpenID Server
Heraldry OpenID Consumer Plugin

  • PHP 

JanRain OpenID
http://taral.livejournal.com/147710.html Server only; conforms to version 1.1.
NetMesh InfoGrid LID PHP
Simple OpenID PHP Class - Small class for consumer. Requires CURL.
phpMyID - Single user server
sfOpenIDPlugin - symfony plugin for OpenID

  • ColdFusion

CFOpenID - Coldfusion OpenID Consumer library
OpenID CFC - Consumer library.

I think OpenID is a wonderful tool and this is just the beginning.

References

[1] OpenID Website : http://openid.net

 


[2] OpenID Libraries : http://openid.net/wiki/index.php/Libraries








}