Pakku’s Blog

For the ones who have recently lived under a rock, OpenID is a decentralized single sign-on system. Using OpenID-enabled sites, web users do not need to remember traditional authentication tokens such as username and password. Instead, they only need to be previously registered on a website with an OpenID “identity provider” (IdP). Since OpenID is decentralized, any website can employ OpenID software as a way for users to sign in; OpenID solves the problem without relying on any centralized website to confirm digital identity.

Will this truly be the future? Will the username/password era soon be over?

OpenID is increasingly gaining adoption among large sites, with organizations like AOL and Orange acting as a provider. In addition, integrated OpenID support has been made a high priority in Firefox 3 and OpenID can be used with Windows CardSpace, which is part of .NET Framework version 3.0 (the .NET Framework version 3.0 comes with Windows Vista by default and can be downloaded for Windows XPsi.

Let’s first take a closer look on the OpenID protocol. Because a picture still tell use more than thousand words, I’ll stick with posting a picture. (Click on it to enlarge)

But for the ones who still don’t get it, Wikipedia perfectly explain how a user logs in with the use of OpenID

“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 this URL 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 it should use a delegated identity (see below). Starting with OpenID 2.0, 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 relying party can validate the shared secret received with the credentials against the one previously stored. Such a relying party is called stateful because it stores the shared secret between sessions. In comparison, a stateless or dumb relying party 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.

OpenID does not provide its own form of authentication, but if an identity provider uses strong authentication, OpenID can be used for secure transactions such as banking and e-commerce.”

So now we all are on the same level, we can go further, to me this system sounds wonderful, but what about the security risks. As a programmer I know that everything is hackable, and things like this are valuable to hack, question is where can we find the weaknesses?

For example, a malicious relying party may forward the end user to a bogus identity provider authentication page asking that end user to input their credentials. On completion of this, the malicious party (who in this case also control the bogus authentication page) could then have access to the end user’s account with the identity provider, and as such then use that end user’s OpenID to log into other services.

In an attempt to combat possible phishing attacks some OpenID providers mandate that the end user needs to be authenticated with them prior to an attempt to authenticate with the relying party. However this then relies on the end user knowing the policy of the identity provider, and regardless this issue remains a significant additional vector for man-in-the-middle phishing attacks.

Other criticisms are that the addition of a 3rd party (the identity provider) into the authentication process significantly adds complexity and therefore possibility of vulnerability into the system. Also this system shifts responsibility for “quality” of authentication to the end user (in their choice of identity provider), a shift that the end user and the relying party (for example their bank) need to understand.

Time will tell if OpenID will be a success, it does have a great advantage above any other login system, but in order to succeed, it has to become more popular, a question round in my group of friend shows that few of them have heard of OpenID, but none has used it or knows how to use it.

The idea is great, now it’s time to get rid of all website’s using their own login system and switch to OpenID to force the world to use OpenID and make the Internet a better place to be.

Pakku