Re: [aerogear-dev] OAuth2 Adapter

Looks good and works fine with FF24 and Chrome27. I was missing instruction how to enable client access in Google Console though, so I added them here: https://github.com/lholmquist/ag-google-drive/pull/1

Other interesting fact is that FF shows "delete" text while Chrome shows wastebin icon, I wasn't looking deeper into that though. Karel On Wed, 18 Dec 2013 14:45:39 -0500 Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > 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 > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev