Tuesday, June 23, 2009

Federated Identity in your Browser

In this post I am going to discuss the background information that will make a case for Federated Identity Management in Browsers. With the advent of new Browser capabilities, and leveraging the new technologies that will be adopted by Federated Identity specifications, I hope to show how Federated Identity Management can be achieved using Browsers.

Federation of Identity serves to enable portability of Identity information across otherwise autonomous security domains. In other words Federated Identity is about using a single Identity to sign into different web sites (over simplifying a bit here). This is not only about your "username" and "password" but also a about other information that identifies a person like, real name, address, nick name, email etc.

Examples of common Federated Identity usage are, using your Google or Yahoo Account to Log in to other sites like Blogger, Youtube etc. In this case the web site allows authentication via any "Provider" that follows a Federated Identity standard like OpenID eg. This is different from using your Facebook or Twitter Accounts to sign into third Party sites. In the latter case it is called Delegated Identity. In other words the web site you are signing into has delegated authentication to Facebook or Twitter.

The way Federated Identity Log ins work is that, when you visit a Site you are redirected to your Identity Provider, eg. Google. You Log in at your Provider, and also "allow" your provider to provide additional information (your name, email etc), and then you are redirected back to the web site. For one this method is prone to Phishing. If a user inadvertently visits a untrustworthy site, the site could redirect the user to a site that appears to look like the users provider and steal his user name and password.

Another problem is that when you visit a site that supports Federated Identity, you cannot log in to the site just by clicking a button. The site for various reasons will choose to support a selected list of providers from which you have to choose from, leading to what is called Nascarization.

Another problem is that of data portability. Let us say you have your identity, profile and social contacts at Google, and you want to change to Yahoo. There is no way to do that seamlessly as of now.

All this begs the question where is the best place to keep your identity information? With You! That's the obvious answer. And the closest that can get to "You" is your Browser. Unfortunately in the current state of affairs of Federated Identity, the browser only plays the role of via media or broker, between the Identity provider and the web site. If the Browser were to manage your identity you could solve all the three problems above in one fell swoop!

However there are two reasons why browsers do not play a greater role in Federated Identity Management.
  1. There is no commonly accepted standard that will allow browser vendors to support this. This would require a specification to allow the browser, identity provider, web sites to speak a "common" language.
  2. Another solution would have been to implement browser plug ins. This would still require the common standard but at least we do not have to wait for the browser vendors. But the problem here is developing plug ins for all types of browsers is not easy (at least up to now).
New browser developments like Jetpack from Mozilla Labs allows you to develop browser plug ins very easily using Javascript. Opera Unite is another effort to empower the browser. All browser vendors are moving in the direction of empowering the browser. What all this means that extending your browser to support a Federated Log in standard is going to be trivial.

So what we really need is a "Federated Identity Standard for Browsers". There must be a working group for this at one of the standards bodies like OpenID, Open Web, Kantara etc. I have not seen such a working group yet.

I intend to demonstrate how a simple Federated Identity standard can be implemented using Mozilla Jetpack, and some minor tweaks to existing Federated Identity provider and consumer software, in a future post of mine.


  1. Being a computer science student I see some difficulties with this approach. How do you intend to make the ID portable? How can the website trust the ID provided by the browser? Looking forward to read the upcoming post on this.

  2. Thanks for the share! When it comes to federated identity management I am not too sure browsers would be secure enough. Very interested on seeing what you develop using Jetpack though. Please keep me posted!