Changes include:

• Added a factory class to simplify object creation
• Added several more types of OAuth message:
  • UserAuthRequest
  • UserAuthResponse
  • AccessTokenResponse
  • RequestTokenResponse
• Added documentation
• Added several serialization/deserialization methods (I.e. convert a Net::OAuth message object to/from an URL, a POST body, an Authorization header, a hash of parameters).
• Added a demo Consumer web application which queries the Google Contacts API.

(We posted screenshots that show how a sample OAuth gadget works for an end-user, as well as information on how to get one working on the Orkut/iGoogle sandbox if you are interested.)

When adding support for OAuth to Shindig we found it useful to add two simple extensions to OAuth, each adding just one additional parameter to OAuth requests, which I’ll describe below.

Key Rotation

One nice thing about gadget containers like Orkut or iGoogle supporting OAuth for the gadgets they host is that gadgets don’t need to bring their own consumer key and secret to the table. If they don’t have any, Shindig will just sign the OAuth request with its keys, and send the request on to the service provider that the gadget wants to talk to. Imagine a large gadget container like iGoogle adopting Shindig and its OAuth support. It wouldn’t scale for Google to negotiate consumer secrets with every OAuth service provider that iGoogle gadgets may want to talk to. It’s much more likely that iGoogle would just use the RSA_SHA1 signature method on outgoing OAuth requests, publish its public key, and hope that service providers would accept requests signed by that public key.

What if iGoogle wants to change its signing key every now and then (which it should – it’s called good cryptographic hygiene)? It should be easy for service providers that have chosen to accept iGoogle’s signing key to switch over to the new signing key. That is what the key rotation OAuth extension is for.

Gadgets Extension

Remember how I said that gadgets don’t have to bring their own consumer key and secret to use OAuth? If they don’t, Shindig will just sign the OAuth requests with its private RSA key. But how will a service provider then know that the request came from a particular gadget? That’s what the second new OAuth extension is for – it simply says that in this case, the OAuth consumer should include the identifier of the gadget into the outgoing OAuth request. This identifier is the URL where the gadget is hosted. Service providers that support the gadgets extension can tell users at token-authorization time which gadget container is requesting access, and on behalf of which gadget access is requested. That improves transparency to the user and makes it clear that both the gadget container and the gadget itself should be deemed trustworthy before granting an access token to them.

These features are being implemented as we speak. It’s not too late to join the discussion.

Photo by Anand Iyer.

It’s exciting and rewarding to be on the side of the open web lately. APIs are open, content is being licensed in proactive, less restrictive terms, contact lists are being freed up, and people will be increasingly able to connect with friends, whether they have an account with every website on the web or not.

When we started the OAuth project, we aimed to solve problems that two small, independent web companies had (namely, Ma.gnolia and Twitter). We didn’t have any grandiose ideas that Google or Yahoo or AOL or MySpace would ever pick up on our work, only that we needed to solve the problem in a way that was vendor neutral, but also didn’t unnecessarily reinvent the wheel.

Turned out that our work was useful not just for its technical merits, but that it also enabled large companies like Yahoo and Google to have a common protocol — shepherded by independent individuals without much of an agenda save producing good tech — to hash out the slight differences in their own protocols and move to a shared standard.

Where there used to be BBAuth, FlickrAuth, AuthSub and similar protocols, there will eventually be primarily, or only, OAuth. And the time in which its taken to get here has been microscopic compared with similar adoption cycles in the past. That, less than six months since the final spec was released, Google is already championing the protocol as a lynchpin to its overall “open web” strategy alongside other standards efforts like OpenID and OpenSocial really demonstrates the power of devoted, focused community groups that form around solving fairly straight-forward and well-articulated problems, using open and distributed collaborative means to come to some kind of shared agreement, understanding and implementation approach.

There are inevitably still any number of issues to be addressed in our work, but that we’ve come so far so quickly, and with such recognition, is something I think is worth pausing for a moment and considering before we dive back in and keep pushing forward.

Tim’s looking for feedback and review, so join the list and let him know what you think.