When your dealing with trusted applications who communicate on behalf of a user who has already granted that application access (through the fact of adding it to their page), 2 legged oauth seems to be exactly what your looking for?
With 2 legged oauth you know the app id from the consumer key/secret (simple lookup in db), and you can verify that the user id it's making a request for has the actual app installed, in which case you allow access.. no need to go through any oauth redirect dances, etc, and it uses a well defined protocol for doing so, with the added benefit of not having to write it your self, and knowing a lot of smart people looked at the security of it for you. The last and quite large benefit is that there's already a number of OpenSocial REST libraries available for various languages which support 2 legged oauth out of the box, so it'll be easier for the app developers too. -- Chris On Wed, Jan 21, 2009 at 4:20 PM, sonic <[email protected]> wrote: > Thanks chris for your quick and clear response. > The requirements arise from the fact that I want to set up a shindig on my > site, > and provide social api for some developers to write applications which > can be embedded > on my site, but the target developers perfer to use restful like api > rather than javascript api. > And supporting 3 legged oauth is not my goal. > > My initial idea is do something like securitytoken. > Given the gadget domain is www.exampleapp.com, I generate a one time > token(st) which includes user id, > app id e.g(shindig has already done this), and pass the st as > parameter to application's home server, > the url of iframe may be http://www.exampleapp.com?st=***&other parameters > then the application's home server can use that one time token to > exchange a long lived token(may be 30 mins or more) > and get user's data via restful api, authenticated by the long token. > Actually it's pretty much like the authentication process of gadget > javascript api. > I know there may be some flaws of this approach, can you shed some > light on it? Thanks very much again:) > > > > On Wed, Jan 21, 2009 at 10:15 PM, Chris Chabot <[email protected]> wrote: > > Hi Cai, > > > > That completely depends on the situation. > > > > If your building both parts, there is nothing limiting you from making > RPC > > calls (of any kind) to a different back-end, so taking social requests > and > > proxying them to a different OpenSocial back-end is quite possible as > long > > as you implement something that does that relaying. (there's no standard > > solution for this though) > > > > If you want to talk to someone else's OpenSocial back-end, then you need > to > > talk to that other party to see if they will allow this, and what kind of > > authentication is required to do so . > > > > The REST end-point is intended to allow a gadget to talk to it (using a > > short lived security token), a remote server to talk to it on behalf of a > > gadget that a user has installed (2 legged oauth), or on behalf of a user > > (without a gadget being involved) through 3 legged oauth, where the user > has > > to grant permission on the social site before said communications can > take > > place. > > > > None of those solutions fit your requirements, so you would have to agree > on > > a different way of getting access to their REST end-points. > > > > On Wed, Jan 21, 2009 at 9:43 AM, sonic <[email protected]> wrote: > > > >> hi opensocial experts, > >> > >> I understand gadget domain should be a different domain other than the > >> container domain for some security reason, and gadget domain should > >> still be under container's control. > >> I am just wondering if it's possible to host a 'gadget'(I just borrow > >> this word) on a third party domain, then the gadget home server can > >> communicate with the container's server via restful api? Is it a > >> standard way to use shindig? > >> > >> -- > >> Cai Jian > >> > > > > > > -- > Cai Jian >
