spec proposal: OAuth summary
Brian Eaton
she specified which timezone...)
OAuth is designed to allow users to share data across services without
needing to share passwords. Allowing gadgets to use OAuth to mashup
data would be a great feature for the gadgets platform. OpenSocial
0.7 contained an incomplete specification of how OAuth should work.
Dirk Balfanz and I have fleshed out that specification and built a
working OAuth proxy service into Shindig. We'd like to propose some
enhancements to the gadget specification to make it easier for gadget
developers to use OAuth.
I'm going to start with goals, since that's what most people will care
about. OAuth in opensocial should support the following use cases:
- It should be possible for a user to grant a gadget permission to
access data from third-party services
- The user shouldn't have to give out their password to grant access.
- It should be possible for either the third-party service or the user
to revoke access once it is no longer needed.
- It should be possible for a third-party to provide a user with a
gadget that can automatically access their data.
- It should be possible for a gadget to mashup data from multiple third-parties.
- It should be possible for all of this to happen without the gadget
gaining access to any long-lived secrets. Gadgets should see data,
not authentication information.
- Gadget authors should be able to use OAuth by making a single
function call in their gadget.
So that's what we're shooting for. The rest of this e-mail is
background on OAuth. The next two e-mails I send out will have
details on the spec changes I think we'll need.
Some background for people unfamiliar with OAuth (the spec lives at
http://oauth.net, if you want to delve deeper. The appendix to the
spec is required reading if you need to know roughly how the protocol
works. The spec itself can be skipped unless you intend to implement
the protocol from scratch.)
Terminology:
User: a user with an account on a container and a different account on
a service provider.
Service: a service that holds the user's data
Consumer: an entity that would like to access the data with the user's
permission. For OpenSocial, the consumer is a gadget running in a
container.
Request token: a temporary token used during the OAuth protocol to
help a consumer and service provider negotiate access.
Access token: the request token can be exchanged for a long lived
access token that provides access to the user's data.
Configuring the OAuth protocol between a consumer and a service
provider requires several bits of data:
- request, authorization, and access URLs: URLs used during the
protocol. The format of the data sent to and from these URLs is
defined by the OAuth protocol.
- data URLs: URLs used to access data. Input and output is free form.
- consumer key: name used to identify a consumer (i.e. a gadget and a container)
- consumer secret: secret used to identify a consumer. This can take
the form of a shared secret or a public/private key pair.
Some of this information, such as the URLs involved, is public
information and can be declared in the gadget XML file. The consumer
key and consumer secret need to be held by the container, since if
they are made public the security of the protocol is broken.
Containers, gadget authors, and service providers are going to have to
distribute those secrets out of band for now. We're proposing
extensions to OAuth to try to make that key distribution a little
easier.
OK, that's all the background I'm going to do for now. Next up: XML
spec changes.
Cheers,
Brian
Julian Bond
>I'm going to start with goals, since that's what most people will care
>about. OAuth in opensocial should support the following use cases:
And the RESTful Data APIs. or is that so well understood that it's not
worth mentioning here?
--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Screw Cap On Tightly
Brian Eaton
>
> Brian Eaton <bea...@google.com> Fri, 18 Apr 2008 23:38:14
>
> >I'm going to start with goals, since that's what most people will care
> >about. OAuth in opensocial should support the following use cases:
>
> And the RESTful Data APIs. or is that so well understood that it's not
> worth mentioning here?
I'm pretty sure that the RESTful APIs are going to use signed fetch,
and it's possible that they will use full OAuth. But I don't
understand how that is going to work well enough to want to document
spec changes associated with the RESTful use cases. Please consider
my proposals to be gadget-to-server specific for the moment.
Hopefully the RESTful API spec changes will include details on how
they will use OAuth.
Cheers,
Brian