OAuth 1.0 and OpenID 2.0 went final one day apart. Each has a very well defined purpose and were designed to work well with each other. OAuth’s primary focus was a way to delegate authorization, mostly in the realm of APIs; and OpenID creates a distributed identity service. When put together, OAuth allows users to use their OpenID with widgets and other services, and that was one of the initial driving forces behind developing OAuth. For the most part, each protocol does its thing well, and plays well with its counterpart. But from a technology standpoint, we made a bit of a mess.
If you strip both protocols of their stated objectives, what is left is a standard way of asserting claims. A user comes to a party A and makes a claim (“I own this URL” or “These photos are mine”), party A sends user to party B (who has the authority to validate that claim) where the user does something, then goes back to party A with proof that the claim is true. Party A has verified the claim and provides services. Within OpenID, that claim is the ‘claimed identity’. For OAuth, it is ‘access to resources’.
From a marketing and political perspective, these are two separate efforts. Each is focused on selling a different claim (identity vs. authorization) and provides custom solutions needed to address the unique nature of those claims. But from a technical perspective, there is no reason why one cannot accomplish what the other was meant to do.
OAuth provides tokens as a mean to hold on to a verified claim, which is very useful for APIs and other long-term access requirements. The presence of tokens allows for the delegation of authority instead of having to validate the claim for every single resource request. OpenID provides a way to convert a URL or XRI into an identity identifier called discovery as well as other security features that are unique to authentication.
Both protocols can be easily extended with very little effort to cover the full functionality offered by the other protocol. OAuth needs a parameter to hold a claim (something the OAuth community has been discussing in the form of token attributes), while OpenID needs to return a token as part of the validation process which can be used to access resources owned by the user.
In fact, at one point during the OAuth development process, Kevin Turner and the team at Jan Rain proposed to implement OAuth as an OpenID extension. Their proposal was to simply use the claim verification component of OpenID without having to actually support OpenID identities. There were good reasons to reject that proposal, both technical and political.
On the technical side, OpenID implementation isn’t trivial, especially OpenID 2.0 (when done right). The cryptography requirements of OpenID are much more complex than OAuth and are not something most API users are able to use. On the political side, people see OpenID solely for its open distributed identity value, and it would be hard to explain to companies not using OpenID, that they can use the technology for API authorization without actually supporting open identities.
So far, this is nothing more than a difference of opinions between the two O’s. The problem is specific to one of the roles in the OpenID / OAuth dance. As described above, both protocols define a love triangle. OpenID has an End User, Identity Provider, and Relaying Party. OAuth has a User, Service Provider, and Consumer. They pretty much mean the same thing. Trouble begins when an Identity Provider is also a Service Provider, or in other words, a service which provides both distributed identity services and other resources.
In this dual role, both protocols are needed but when combined, create a very inefficient solution. First, it requires double the implementation and maintenance cost for both providers and consumers and makes things twice as complicated. Developers use one interface to fetch one resource (identity) and then another completely different interface to fetch another resource (photos, messages, social graph, etc.). It also makes the user experience clunky at best, being redirected back and forth repeatedly for no good reason.
The problem has been identified by both the OpenID and OAuth communities, but so far, the two are unable to reach an agreement of how to best resolve it. At IIW, Joseph Smarr of Plaxo has a session about this particular dual-role scenario, and while it was a good discussion, very little came out of that. But getting to a solution requires either extending one to replace the other, or combining them (something David Recordon suggested at some point), and neither option is simple.
A combination means that either OAuth gets more complex for the non-OpenID use cases, or OpenID loses some hard fought accomplishments of getting vendor support. Extending one to support the other may lead to many incompatible extensions and will make developers life more complex. The solution most likely lies somewhere in between where a combined protocols finds a way to be both backward compatible and simple.
The first step in moving towards a solution is finding the a place to have this dialog between the two communities. The question is, where is that place?