(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.