OpenID & OAuth – complimentary or competing?

Been trying to update myself with whatever’s been happening in the security space. There are two new specifications in the realm of authentication and access control that seem to have potential to create a huge impact : OpenID and OAuth. Unlike other efforts in this space, like say the Liberty Alliance these specifications are (thankfully !) simpler and seem much more practical to use and implement.

OpenID

The vision of OpenID is to create a single unique identifier for a user, across the Web. This ID is in the form of a URI, any URI as long as the user has control over it. There are a bunch of OpenID providers (in OpenID parlance, an OP ) like http://www.myopenid.com. Sign up with them and you get your own OpenID URI. If you already own a registered domain name, then you can use the same as your OpenID. All you need is a simple setup to delegate your calls to an OpenID server. Finally, if you are really paranoid, you have the option to run your own OpenID server too.

Sites that accept OpenIDs are called Relying Parties or RP. When you use your OpenID URL in an RP, you get redirected to your OpenID Provider, you authenticate and get redirected back to the RP. The OpenID protocol ensures that the RP knows if you have successfully authenticated or not.

The industry response to OpenID has been lukewarm. All AOL users now have an OpenID. Many prominent sites have started supporting OpenID in some form or the other. You can find a list of supported sites at http://openiddirectory.com/

OAuth

OAuth is defined as a “an open protocol to allow secure API authentication in a simple and standard method”. Don’t be tempted to think that OAuth implies “open authentication”. It doesn’t. It is closer to “open authorization”. Let’s say you are registering as a delegate on a conference website. With OAuth it is possible for the conference website to automatically add the event to your google calendar or yahoo calendar with your consent (assuming google and yahoo support OAuth). How does it work ? Well, once you decide to let the conference website add an event to your google calendar, you get redirected to google. On google , you explicitly authorize the conference website to modify your calendar. After this authorization, the conference website will have permission to modify your calendar data.

Most portals already offer APIs to achieve this functionality, albeit in a proprietary form. Google’s AuthSub and Yahoo’s BBAuth are good examples. OAuth represents a standardization of this functionality.

Complimentary or Competing?

In theory, OpenID and OAuth are complimentary. OpenID helps determine who you are (“authentication”) and OAuth defines how you give access to protected data (“authorization”). A site that supports OAuth could also support OpenID for authentication.

However, my view is a little different. Given that the current trend amongst the internet giants (Google, Yahoo and MSN) is to : (a) increase their user base (b) make more people use their services, OpenID might not excite them. It works against (a). Even AOL, which has 63 million OpenIDs does so by being an OP. They are still not a relying party (RP). It will be interesting to see how they support it. Will you be allowed access AOL services with any OpenID ? Will you be asked to fill a whole bunch of profile info after login?

OAuth on the other hand ought to please these companies. They can keep their entire use base and data to themselves and yet allow third parties to integrate into their services. The more the number of external websites that integrate with them, the more their services will be used (Almost all popular websites today release a "developer” API for the same reason).

OAuth, in a way, makes the case for OpenID weaker. If OAuth was not around, it would have been tempting to use OpenID in order to expose one’s services to a larger audience. With OAuth, that argument no longer holds true.

Hence in my opinion, 2008 will see a rise of OAuth support while OpenID adoption might not be phenomenal.