The token passed in st doesn't necessarily have to be the same token used for OAuth or secure phone home. It's mostly intended to pass secure information from the container into the gadget so that the gadget can pass it up to back ends as appropriate. It's mostly intended as an alternative to container mediated access.
The ideas can certainly be applied to various other security solutions, such as those required by open social, but it is very much an implementation detail at this point. I'd be weary of trying to overload the single concept too much, because it'll yield an unwieldy interface and make deploying shindig that much harder. On Feb 3, 2008 9:22 AM, Reinoud Elhorst <[EMAIL PROTECTED]> wrote: > On 2/1/08, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > > On Feb 1, 2008 12:04 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > > > Reinoud's post about his first steps with Shindig sparked an > > > interesting discussion I want to pull into a separate thread. Our > > > story so far: > > > > > > Reinoud suggested that the container and the gadget server not need to > > > share the same data sources, just a few encryption keys.[1] > > > > > > Kevin agreed. [2] > > > > > > I said I didn't think not sharing data sources was realistic, because > > > too much information would need to go in the security token. [3] > > > > > > Kevin also agreed with that, at which point I got confused. > > > > > > The main reason I think we'll need to share data sources between the > > > container and the gadget server is OAuth; there are per user access > > > tokens that the gadget server needs access to. That implies the > > > container and the gadget server are both using the same backend for > > > their users. Or am I missing something? > > > I assume you're talking about the current "phone home" functionality, not > the SPI API? For the latter, I haven't though that one completely through > yet, pehaps little use in that until we have a spec. > > As far as I can tell from the documentation [1], the secure phone home > doesn't use any access tokens. All it does > is use the shared secret (or public/private key) to sign the viewerid (if > available to the gadget), ownerid and application URL. > > > Every container could have it's own back end that understands the security > > token. There's no need to pass anything other than the most basic data > > required to authenticate. Example: > > > > Container generates token that contains: current viewer, owner of the > > current page, and the url of the gadget that was rendered. It gets > passed > > to the iframe as #st=<base 64 encoded token> > > > > opensocial feature uses gadgets.io.makeRequest and forwards the token > > itself > > to the target back end (alternatively, if it's on the same host, it > could > > simply make a normal XHR). > > > > App data back end decrypts the token and returns data for whatever the > > current request requires (friend graph, app data, whatever). > > > > The *gadget server* doesn't care about authentication (other than > > validation > > of tokens in some special cases, like signed proxy requests). It's the > > *app > > data* servers that actually need to know about this. It's possible for > the > > gadget server to also be an app data server, of course, but I think that > > this is impractical for real websites. > > > > I agree with Kevin here, although I don't think we can step over the > second usage of the taken so easily. > I think Kevin made clear that any call that is forwarded to the > data-API-backend of the container, is not an > issue. The gadget server does nothing here but pass on, and the API > backend obviously has shared data backend (and probably shared code) > with the container site. > The second usage is the "secure phone home". Here the gadget server needs > to > 1) Check whether the st is valid (e.g > . check the signature) - this would require a shared secret > 2) Extract the ownerid and gadget-url from the st (I don't think these > values need even be encrypted; both are always known to the gadget) > 3) Check if the gadget has access to viewer data, in that case extract the > viewer_id from the token > 4) Add ownerid, gadget url and, if visible, viewerid to > the url-to-be-called, add a timestamp & nonce, > calculate the oauth_secret (either RSA or HMAC) and add that > > Now, from the list above, I think only step 3 > might need some more thought: how can the gadget server know that the > viewer information is visible. I suggested before to use a second > token for this, and I still believe this can be done securely. > Obviously this second token would need to be checked for > validity > by the gadget server as well, so for this possibly a second shared > secret is needed. > > Reinoud > > [1] http://code.google.com/apis/opensocial/docs/0.7/spec.html#remote >
