Kevin Marks has been bugging me for awhile to understand how
OpenSocial makes use of two-legged OAuth.  I reached out to the team
and here's their description (via Evan Gilbert).  In general it seems
like they're more making use of OAuth's RSA signature mechanism rather
than the user authorization and access token flows.

1. Developer (let's say iLike) creates a gadget that runs in multiple
containers.
2. User Bob is views iLike gadget on MySpace and the iLike gadget
needs to make a request back to iLike's home server to get private
data (let's say the user's favorite bands)
3. iLike gadget makes a JavaScript call to get this data from iLike
servers. This call uses a gadgets API (gadgets.io.makeRequest) that
proxies the request through MySpace servers.
4. MySpace adds validated URL parameters to the request - most
importantly opensocial_viewer_id and opensocial_app_url. MySpace then
signs the request and then forwards on the request to iLike's servers.
4.5 iLike can choose to sign request with MySpace's private key or
with a shared secret between iLike & MySpace.
6. iLike verifies the signed request, using MySpace's public key or
the shared secret.
7. iLike checks verifies opensocial_app_url to make sure this isn't a
different gadget asking for data.
8. Lastly iLike looks up user data based on opensocial_viewer_id and
returns it back to the gadget.

Intro to signed requests:
http://wiki.opensocial.org/index.php?title=Introduction_To_Signed_Requests
Validation of signed requests:
http://wiki.opensocial.org/index.php?title=Validating_Signed_Requests
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to