Re: [aerogear-dev] OAuth2 Adapter

i've created a new example here, https://github.com/lholmquist/ag-google-drive that hopefully shows the flow a bit On Aug 29, 2013, at 2:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > i did get it to work > On Aug 29, 2013, at 2:04 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> This update is really cool, is the pipe test flow working ? >> >> >> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; >> wrote: i've updated the sample again >> https://github.com/lholmquist/oauth2test >> >> this time i added a pipe object and used pipe.read to see how the flow >> would be >> >> >> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >>> i've updated the sample app with the new flow >>> >>> https://github.com/lholmquist/oauth2test >>> >>> >>> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >>> >>>> ok, Kris had some thoughts on a better flow, so i refactored the code a >>>> bit and i think i like this way a bit better. >>>> >>>> New Flow - Client Flow - Standalone for now, possible integration with >>>> pipes >>>> >>>> First Time - No Access Token stored( in localStorage ) >>>> >>>> User will create the Authorization Object stuff with settings/options >>>> >>>> var thing = AeroGear.Authorization(); >>>> >>>> thing.add({ >>>> name: "coolThing", >>>> settings: { >>>> clientId: "12345.apps.googleusercontent.com", >>>> redirectURL: "http://localhost:8000/redirector.html", >>>> tokenValidationEndpoint: >>>> "https://www.googleapis.com/oauth2/v1/tokeninfo", authEndpoint: >>>> "https://accounts.google.com/o/oauth2/auth", revokeURL: >>>> "https://accounts.google.com/o/oauth2/revoke", scopes: >>>> "https://www.googleapis.com/auth/userinfo.profile", prompt: "force" >>>> } >>>> }); >>>> should have the ability to specify more settings, based on the spec >>>> >>>> The user would then call some method( currently not good names are >>>> coming to me, maybe validate ) that takes success and error callbacks. >>>> >>>> thing.services.coolThing.validate({ >>>> success: function( response ){ >>>> console.log( "Should be response from Validating the access >>>> token", response ); }, >>>> error: function( error ) { >>>> //should contain a constructed URL for the user >>>> console.log( "error", error ); >>>> } >>>> }); >>>> Since this is the first time, the error callback will be called and will >>>> contain the constructed URL that the user should do the popup redirect >>>> dance with to get an access token. >>>> >>>> what "dance" they do is up to the developer >>>> >>>> Once that happens and they have the access token, they would call the >>>> validate method again. >>>> >>>> this makes sure that the token they recieved is validated and will also >>>> return some other meta data related to the token, like refresh time. >>>> >>>> Once the token has been validated, it will be stored in localStorage and >>>> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is . >>>> >>>> so in this example it would be something like: >>>> >>>> ag-oauth2-12345.apps.googleusercontent.com >>>> There is one problem i can see here though. If the user has to >>>> applications with the same client ID but different scopes assigned, this >>>> would be a problem. That use case could be considered bad practice anyway >>>> >>>> The user can then call the "callService"( yes, again, crappy name ) >>>> method to get access to the service they want. >>>> >>>> thing.services.coolThing.callService({ >>>> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", >>>> success: function( response ){ >>>> console.log( "Should be the response from the call", response ); >>>> }, >>>> error: function( error ) { >>>> console.log( "error", error ); >>>> } >>>> }); >>>> All these methods would have success/error callbacks. >>>> >>>> Token Expiration >>>> >>>> If the user makes a call to a service, using the callService method, and >>>> they recieve an error such as not authorized or token invalid or token >>>> expired, I'm thinking we send what the "contructed URL" should be, >>>> similar to the validate method described above. >>>> >>>> Since this is a Client Side flow, there is no refresh token, so the >>>> client wouldn't be able to refresh the access token without doing the >>>> "dance" again. >>>> >>>> >>>> >>>> >>>> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >>>> >>>>> i've hacked together a sample app that shows sort of the flow. >>>>> >>>>> https://github.com/lholmquist/oauth2test >>>>> >>>>> it is still very rough >>>>> >>>>> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; >>>>> wrote: >>>>> >>>>>> +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 >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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