Re: [aerogear-dev] OAuth2 Adapter

+1 keep it simple, please Lucas Holmquist wrote: > > On Aug 27, 2013, at 3:39 AM, Sebastien Blanc <scm.blanc(a)gmail.com > <mailto:scm.blanc@gmail.com>> wrote: > >> Hi, >> That sounds good ! >> Just one question, instead of using the callApi function couldn't we >> pass the oauth module (called 'thing' in your example) to the pipe >> directly, using the 'authenticator' setting. Behind the scene, the >> pipe manager will append the oauth token to the query or add the >> bearer header ? > > I'm not sure if that is what this is going to do. This is more of an > Authorization thing and i don't think it totally fits the pipeline > stuff. ( or it would make it a bit more complicated, and we want to keep > it simple ) > > > i should probably change the method to be "authorize" instead > >> Seb >> >> >> >> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist <lholmqui(a)redhat.com >> <mailto:lholmqui@redhat.com>> wrote: >> >> >> OAuth2 AeroGear Workflow - High Level >> >> >> Using Google api's >> >> /Server Side/ >> >> 1. user needs to first create an "application/project" to get an >> api key >> 2. Then they would choose the services/api's then would like >> there application to access >> 3. other google server related items.... >> >> /Client Side/ >> >> 1. Create a new OAuth2 module thing >> 2. Get access token for the services would need to specify the >> services they would like to access >> 3. validate the token >> 4. make calls to the service >> >> >> API >> >> |var thing = AerGear.OAuth2({ >> name: googleEndPoints, //Just a Name >> clientID: "12345" //The client ID of the app from the API console >> settings: { >> permissions: "..", >> ... >> } >> }).somecoolmodulename.googleEndPoints; >> | >> >> /Settings: Multiple settings based on paramters here >> <https://developers.google.com/accounts/docs/OAuth2UserAgent>/ >> >> /Methods/ >> >> >> authenticate >> >> this will authenticate with the server to get the access token and >> then validate the token, once that is all good then the response >> is returned. >> >> |thing.authenticate({ >> success:{}, >> error:{}, >> settings: { >> //probably some settings here, like URL overides and such >> } >> }); >> | >> >> >> callApi >> >> not really a good name, but it would basically call the remote >> api/services. we could either do a query string option or a Head >> option >> >> example: >> >> |curl 'https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' >> | >> >> or >> >> |curl -H "Authorization: Bearer {accessToken}" https://www.googleapis.com/oauth2/v1/userinfo >> | >> >> code: >> >> |thing.callApi({ >> service: "userinfo", //don't really like this name either >> success:{}, >> error:{}, >> settings: { >> ... //overridable baseURLs? >> } >> }); >> | >> >> >> revoke >> >> again, maybe not the best name. calls the "revoke" service, to >> remove access to permissions >> >> |thing.revoke({ >> success: {}, >> error: {}, >> settings: {} >> }); >> | >> >> Behind the scenes on all these calls, the "access_token" is >> beining used and possibly refreshed for the user, so they don't >> have to worry about it. They just need to call authenticate first. >> Maybe we can have a refresh method if the user wants to refresh >> the tokens themselves. this would do the token "dance" >> >> >> >> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira <bruno(a)abstractj.org >> <mailto:bruno@abstractj.org>> wrote: >> >>> +1 I think is a good start to us. >>> >>> Kris Borchers wrote: >>>> I would like to see that but what you are saying makes sense. It >>>> sounds like where I was headed with the Basic and Digest >>>> adapters before I ran into browser security issues with headers. >>>> I think and authorization API that basically just wraps itself >>>> around secured endpoints works for me. >>> >>> -- >>> abstractj >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev