Monday, May 4, 2009

OpenID's hidden value in Application Integration

I haven't seen any articles discussing this subject - but let me know if you know of any and i'll link.

OpenID is a hugely valuable standard protocol for federated authentication and by the looks of things adoption is and will coninue to grow at a phenomenal rate.

The advantage of OpenID over traditional authentication systems is well known - it saves you having to remember multiple usernames and passwords. An additional advantage of OpenID over other Internet authentication systems is that it is completely decentralized and anyone can create their own authentication provider.

Consider an enterprise that has some internal applications that can't be seen by the web itself. That enterprise can set up an OpenID provider to let all their staff log into these internal applications. Additionally however they can allow that provider to be seen from the outside world and so allow staff to log onto applications on the web using that same OpenID.

Cool! However there is an additional benefit when integrating applications which isn't quite as explicit and you really only notice at development stage. In particular this is very important for creators of 3rd party software. That is:

If a 3rd party application supports OpenID then no matter the language or platform it can be easily integrated into an existing software site or portal.

What do i mean by this? Well recently I created a web site that used a 3rd party open source system that had traditional basic authentication as well as OpenID. Great. However later on i wanted to add a nice blogging feature using another 3rd party ... but the problem was they didn't support OpenID.

Now, let's ignore all the technical detail here such as Single Sign On between applications - sure this is cool but i'd be willing to bet that even if the user had to log in using their OpenID twice into these two applications it is miles ahead of the common current issue where you suddenly need to remember a username and password again (and all the management that goes with that). Consider the case where most of us may integrate 4 or 5 separate systems to create a solution and suddenly the fact that ONE of then uses OpenID but the other 4 require old style username/password authentication really isn't much of a benefit.

In my case i chose not to go for them. I simply didn't have time to write OpenID support for their products. I was quite happy for the applications to run independently on the server with a simple link bewteen each ... even if they had to log in to each - so long as i didn't have to manage duplicate accounts. The great thing though is that the managament of their login details etc could all be done centrally. I know from my experience supporting OpenID.ORG that the time taken to support users dwarfs almost everything else you do.

So although it may sound obvoius that an OpenID account can really help you log into multiple applications with the same details, it's not until you start pulling together 3rd party applications you realize how valuable this is even on a single website or portal.

Going back to our enterprise - they can now create a cool portal that integrates custom software, 3rd party products & remote services,  without worrying about user managament. And i know from current personal experience how big a win that will be.