Exactly, most still true in OAuth2.0 Consumer implementation. Just would like to point out a few things that's added for OAuth2.0 consumer implementation. 1. Gadget developer could still define provider information in gadget xml like follows. <OAuth2> <Service name="googleAPI_test" scope="https://www.google.com/m8/feeds/";> <Authorization url="https://accounts.google.com/o/oauth2/auth "></Authorization> <Token url="https://accounts.google.com/o/oauth2/token";></Token> </Service> </OAuth2> However it can also just reference the service that's pre-registered with the container. We're thinking about the usecase that several gadgets may have registered with the same service provider. Even each gadget may have different client id/secret, they do have the service provider information. It depends on each implementation to tell the gadget which OAuth2 services are pre-registered with container. It probably makes sense to provide such information when gadget register itself (together with the oauth details ) with the container, gadget developer could then select the service and bind client secret with it.
2. For OAuth2, 2 legged scenario is done via client credential flow. thanks, li On Tue, Nov 22, 2011 at 1:32 PM, Ciancetta, Jesse E. <[email protected]>wrote: > >-----Original Message----- > >From: daviesd [mailto:[email protected]] > >Sent: Tuesday, November 22, 2011 10:01 AM > >To: [email protected] > >Subject: Re: Oauth 2 consumer implementation > > > >So how does a gadget know what service name to use since every container > >could define facebook differently. > > The following is based on my understanding from oauth 1.0 and I'm assuming > it still applies to oauth 2.0 -- but I haven't spent much time looking at > oauth 2.0 yet so hopefully someone will correct me if any of this is no > longer applicable... > > I believe the gadget author needs to coordinate registration of their > oauth details with each container they want to run their gadget in -- and > part of that coordination process is for the gadget to define what service > name to register the details under. It's up to the gadget developer to > coordinate with the service provider (like facebook) on getting the oauth > details in the first place though. > > As Ryan mentioned containers are free to define the "coordination" process > any way they choose, but I think a common strategy might be for the gadget > authors to register the details themselves as part of the gadget > registration process. That's what we've done with our internal container > implementation and what I believe we're planning to do in Apache Rave. > > I just took a quick peruse through the opensocial 2.0 specification and it > seems at a quick glance that all of what I've said above still applies, > although it does seem that there is another case where the container can > choose to register container-wide oauth details for a service provider -- I > haven't seen that case used personally though so I can't really say too > much more about that. I assume if a container does that though they would > need to advertise that fact to gadget developers and provide them all the > details they would need to take advantage of it. That would seem to imply > though that users would just be authorizing the container as a whole though > as opposed to a specific gadget which doesn't seem like what you'd want -- > unless the specific gadget is communicated in the request somehow... Maybe > that's part of what oauth 2.0 adds? Hopefully someone who knows more about > this specific use case can comment further. > > One other thing worth pointing out is that the above all applies to > three-legged oauth, but opensocial also supports signed fetch (aka > two-legged oauth) which is kind of nice for when you want to setup an > explicit trust relationship with an external provider where you don't > actually need the user to approve access to their resources. > > >doug > > > >On 11/21/11 2:34 PM, "Ryan J Baxter" <[email protected]> wrote: > > > >> Mike, usually the provider information is configured before hand. Your > >> container could choose to allow gadget developers to register the > provider > >> information, but this is outside the scope of Shindig and the OpenSocial > >> spec. > >> > >> -Ryan > >> > >> Email: [email protected] > >> Phone: 978-899-3041 > >> developerWorks Profile > >> > >> > >> > >> From: Michael Matthews <[email protected]> > >> To: <[email protected]>, > >> Date: 11/21/2011 02:27 PM > >> Subject: Oauth 2 consumer implementation > >> > >> > >> > >> My organization is investigating implementing a "production-ready" > version > >> of Shindig's OAuth2 Consumer implementation. After reviewing the wiki at > >> opensocial.org (in particular > >> > >http://docs.opensocial.org/display/OSD/OAuth+2.0+Consumer+Implementat > >ion+in+ > >> > >> Apache+Shindig) and studying the code to Shindig's sample OAuth2 > >Consumer > >> implementation, it appears that we need to implement our own version of > >> the > >> OAuth2PersistenceModule (e.g. use a database instead of oauth2.json). > >> > >> Some of our remaining questions center around when/how some of the > >OAuth2 > >> related data is persisted. > >> > >> Presumably, a gadget developer will declare what OAuth2 services they > use > >> in > >> their gadget.xml like so: > >> > >> <OAuth2> > >> <Service name="googleAPI_test" > >scope="https://www.google.com/m8/feeds/";> > >> <Authorization > >> url="https://accounts.google.com/o/oauth2/auth";></Authorization> > >> <Token url="https://accounts.google.com/o/oauth2/token";></Token> > >> </Service> > >> </OAuth2> > >> > >> They will then invoke this service using gadgets.io.makeRequest(). > >> > >> Is the expectation that the Shindig container have this OAuth2 provider > >> pre-configured before the gadget is rendered? Is it possible to > register > >> a > >> provider (in this case Google) at runtime? > >> > >> Thanks > >> Mike > >> > >> > >> > > > >
