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
