Re: [aerogear-dev] OAuth2 Adapter

https://github.com/aerogear/aerogear-js/pull/58 I reopened it Sent from my iPhone > On Dec 19, 2013, at 6:08 AM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > > Do we have a PR for it? Works like a charm on chrome, didn’t went well for safari. But let’s start simple, attach a PR please, I’m anxious to test it. > > -- > abstractj > >> On December 19, 2013 at 6:45:14 AM, Sebastien Blanc (scm.blanc(a)gmail.com) wrote: >> >> I just tested the demo, very cool, work as advertised ;) >> >> >>> On Wed, Dec 18, 2013 at 8:45 PM, Lucas Holmquist 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 >>> wrote: >>> >>> i did get it to work >>>> On Aug 29, 2013, at 2:04 PM, Sebastien Blanc >>> wrote: >>> >>> This update is really cool, is the pipe test flow working ? >>> >>> >>>> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist 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 >>>> 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 >> 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 >> 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 >> wrote: >>>> >>>> +1 keep it simple, please >>>> >>>> Lucas Holmquist wrote: >>>> >>>> >>>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc > >> >> >> 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 > >> >> >> 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 >>>> / >>>> >>>> /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/fFBGRNJru1FQ... >>>> | >>>> >>>> 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 > >> >> >> 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 >>>> 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 >>>> >>>> >>>> -- >>>> 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 >> _______________________________________________ >> 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