How OAuth maps onto shinding

[Erik Earle <er...@yahoo.com>]

I have seen some documentation around how OAuth is used in the context of gadgets requesting data but not really a full mapping of what each of the pieces are in OAuth Terms. 

It seemed to me that in most cases, the data APIs of OpenSocial/shinding are the 'service provider' and the gadgets/container/data proxy are the 'consumer'.  What this seems to leave out in terms of OAuth is how the gadget securely makes it's data request to the container so that the container can sign it.  

What stops man-in-the-middle between gadget running on the client and server that will proxy the request for data to the data APIs?  


      

Re: How OAuth maps onto shinding

[Kevin Brown <et...@google.com>]

On Tue, Aug 11, 2009 at 2:10 PM, Erik Earle <er...@yahoo.com> wrote:

> I have seen some documentation around how OAuth is used in the context of
> gadgets requesting data but not really a full mapping of what each of the
> pieces are in OAuth Terms.
>
> It seemed to me that in most cases, the data APIs of OpenSocial/shinding
> are the 'service provider' and the gadgets/container/data proxy are the
> 'consumer'.  What this seems to leave out in terms of OAuth is how the
> gadget securely makes it's data request to the container so that the
> container can sign it.


I think you're mixing up two things.

The shindig gadget server (org.apache.shindig.gadgets) provides an oauth
consumer library that handles 2 and 3 legged outbound requests, including
all opensocial extensions as well as some common oauth extensions for yahoo,
netflix, and other common SPs.

In this model, an encrypted security token is given to the gadget's iframe,
and that encrypted token is passed to the gadget server for use whenever an
authenticated request needs to be made. This includes calls to
gadgets.io.makeRequest, data pipelining (<os:HttpRequest>), and proxied
rendering (the "authz" parameter of the Content element). This is all as
documented in the opensocial specification.

The shindig common components (and primarily used in the social-api
component) makes shindig into an oauth service provider for the opensocial
data apis (REST and JSON-RPC).

As a Service Provider, shindig supports inbound 2 and 3 legged oauth
requests in accordance with the oauth specification (and 2 legged as defined
by opensocial).

The container's only role (aside from furnishing data, of course), is to
provide the security tokens for the gadgets and to implement the oauth
endpoints for the SP (and shindig does most of this for you).

Note that the gadget does NOT use the oauth SP to access social data. The
infrastructure is 99% the same, but we do not use oauth when it is the
gadget making the request. Instead, we pass the same security token that the
gadget server gets for making outbound requests to the data APIs.

What stops man-in-the-middle between gadget running on the client and server
> that will proxy the request for data to the data APIs?


Well, nothing. If you need to guard against man in the middle attacks, you
need SSL. Otherwise I can just hijack your browser cookies anyway.