Doug I don't think we have any flows for OAuth 2 implemented in Shindig that would support server to server calls, at least as far as I know. Adam please correct me if I am wrong. Maybe you could using 2 legged OAuth 1.0a...
-Ryan From: daviesd <davi...@oclc.org> To: <dev@shindig.apache.org>, Date: 06/20/2012 12:57 PM Subject: Re: Adding additional APIs to Shindig Just to clarify where my thinking was headed. I need to provide an oauth client management api for a sandbox ui to use. This ui is not in the same webapp/host as shindig. In fact it's a completely separate environment that supports uploading of a gadget, collecting oauth client credentials, binding those credentials to the gadget, and rendering the gadget. I don't necessarily want the container javascript making the calls. It would most like be server to server. So I was leaning towards just plugging into the current rest/rpc handler and either securing this client management api via a security token or oauth2 (assuming I can do server to server with that). Or the other option is to just create an entirely different endpoint with a plain old servlet on the shindig side and handle the security using a shared secret. I guess I was just wondering if it's better to use the framework provided or homebrew this admin api myself. doug On 6/19/12 2:38 PM, "daviesd" <davi...@oclc.org> wrote: > Thanks Stanton. So it sounds like you were saying to roll my own on this and > not try to leverage off of any existing shindig handlers? I certainly agree > on the security aspect. This would all take place over ssl. > > doug > > > On 6/18/12 5:26 PM, "Stanton Sievers" <ssiev...@us.ibm.com> wrote: > >> Hi Doug, >> >> The largest challenge that I can see with doing what you're trying would >> be to secure that endpoint. Someone being able to add their own client >> could potentially be bad. From my viewpoint, if this is server to server, >> you would want to sign the request with Server 1's private key and encrypt >> with Server 2's public key. Server 2 would decrypt with their private key >> and verify the sender with Server 1's public key before adding the client. >> That would keep any old Joe from calling that endpoint and adding clients >> to your system. You would certainly want the client_secret to not be >> plaintext on the wire. That's my first thought, but I'm no security >> expert. :) >> >> Maybe I'm missing the point altogether... >> >> Thanks, >> -Stanton >> >> >> >> From: daviesd <davi...@oclc.org> >> To: shindig <dev@shindig.apache.org>, >> Date: 06/18/2012 16:28 >> Subject: Adding additional APIs to Shindig >> >> >> >> I have an API I want to add to our custom shindig server that doesn¹t fit >> any current opensocial specs (appdata, people, etc.). The API would allow >> our gadget sandbox webapp to create the oauth2 client and oauth2 gadget >> binding entries (server to server). >> >> So something like >> >> POST /opensocial/rest/oauth2client [client_id, client_secret, >> provider_name, >> application url] >> >> This would allow our sandbox gadget writers to enable oauth2 bindings >> without a third party having to be involved. >> >> My question is, what is the best way to expose such an API? Should I just >> expose it like all the other REST endpoints (and also via RPC) or should I >> just create a servlet with my own authentication scheme (perhaps just >> basic >> authentication)? If I use the existing framework should I use security >> tokens or should I use oauth2? >> >> I¹d be interested in hearing other viewpoints by people who have extended >> shindig with their own APIs. >> >> Thanks, >> Doug >> >>
