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
