On Aug 26, 2013, at 12:11 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > We are planning on adding an OAuth2 adapter to the JS library for 1.3.0. We are going to code against the google OAuth2 playground stuff, but trying to follow the spec as much as possible and try to be as generic as we can. > > I'm not sure if this should be an "adapter" or something different. If it is an adapter of the Authentication plugin( not sure what we are calling the different pieces. pipeline, data manager, etc.), then we should expect to see authentication methods( enroll, login, logout ), but i think this "adapter" should be much more than that. If implementing those methods is possible, I would like to see this as an Auth adapter but then with the other useful functionality on top. If not possible, then do you have a proposal of what an OAuth2 plugin would look like?

> > It should be used to connect to secured services( api ) that a user allows, such as GCM for chrome or the google+ platform, or some other enterprisey thing. > > I'm wondering if this should be a standalone thing. I kind of like this idea so when we do social login, which will most likely have OAuth2, we can just access it. > > Thoughts? > > > > > _______________________________________________ > 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

On Aug 26, 2013, at 12:25 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > On Aug 26, 2013, at 1:16 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Aug 26, 2013, at 12:11 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >>> We are planning on adding an OAuth2 adapter to the JS library for 1.3.0. We are going to code against the google OAuth2 playground stuff, but trying to follow the spec as much as possible and try to be as generic as we can. >>> >>> I'm not sure if this should be an "adapter" or something different. If it is an adapter of the Authentication plugin( not sure what we are calling the different pieces. pipeline, data manager, etc.), then we should expect to see authentication methods( enroll, login, logout ), but i think this "adapter" should be much more than that. >> >> If implementing those methods is possible, I would like to see this as an Auth adapter but then with the other useful functionality on top. If not possible, then do you have a proposal of what an OAuth2 plugin would look like? > > Just using Google As an example, i'm not sure if there would be an "enroll" method, since that would be google's flow. but we could do login/logout. I don't think enroll would really work anywhere since you would need to do the token "dance" first. I see OAuth stuff more of an authorization api than an authentication api > > > let me gist a workflow for a standalone thing. 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.

> > >>> >>> It should be used to connect to secured services( api ) that a user allows, such as GCM for chrome or the google+ platform, or some other enterprisey thing. >>> >>> I'm wondering if this should be a standalone thing. I kind of like this idea so when we do social login, which will most likely have OAuth2, we can just access it. >>> >>> Thoughts? >>> >>> >>> >>> >>> _______________________________________________ >>> 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

+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

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 ? Seb On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: OAuth2 AeroGear Workflow - High Level Using Google api's Server Side • user needs to first create an "application/project" to get an api key • Then they would choose the services/api's then would like there application to access • other google server related items.... Client Side • Create a new OAuth2 module thing • Get access token for the services would need to specify the services they would like to access • validate the token • 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/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&gt; 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

On Tue, Aug 27, 2013 at 9:56 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: Indeed it will be less intrusive to do as suggested by Seb. using something like: pipe.call({…}) Well, I was more thinking using our actual API, for i.e var customPipe = AeroGear.Pipeline([{ name : "customPipe", settings : { authenticator: thing } }]).pipes[0]; Still on callAPi section where do we pass the access token? in the settings section? I think that after thing.authenticate() we don't have to worry to pass the token, it's automagically added. Coud we put the 'service' into settings too? ++ Corinne On Aug 27, 2013, at 9:39 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; 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 ? > Seb > > > > On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > OAuth2 AeroGear Workflow - High Level > > Using Google api's > > Server Side > > • user needs to first create an "application/project" to get an api key > • Then they would choose the services/api's then would like there application to access > • other google server related items.... > Client Side > > • Create a new OAuth2 module thing > • Get access token for the services would need to specify the services they would like to access > • validate the token > • 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/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&gt; 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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 ?

Seb On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: OAuth2 AeroGear Workflow - High Level Using Google api's Server Side user needs to first create an "application/project" to get an api key Then they would choose the services/api's then would like there application to access other google server related items.... Client Side Create a new OAuth2 module thing Get access token for the services would need to specify the services they would like to access validate the token 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/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&gt; 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

On Aug 27, 2013, at 6:04 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > On Aug 27, 2013, at 3:39 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; 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 ) Though I understand what you're saying here, I was kind of hoping for both options with this adapter. What do you think about: OAuth2 adapter is used for Auth as you described Also can be set as the authenticator on a pipe. We could provide config options to either go through the auth process or just provide an error and let the dev handle it

Something like that. Thoughts? > > > 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&gt; wrote: >> OAuth2 AeroGear Workflow - High Level >> >> Using Google api's >> >> Server Side >> >> user needs to first create an "application/project" to get an api key >> Then they would choose the services/api's then would like there application to access >> other google server related items.... >> Client Side >> >> Create a new OAuth2 module thing >> Get access token for the services would need to specify the services they would like to access >> validate the token >> 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/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&gt; 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

+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

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

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 pipesFirst 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 <scm.blanc(a)gmail.com&gt;&gt;&gt; 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 <lholmqui(a)redhat.com&gt;&gt;&gt; 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/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 <bruno(a)abstractj.org <mailto:bruno@abstractj.org <bruno(a)abstractj.org&gt;&gt;&gt; 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<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<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<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

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

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

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

Hello All, I've implemented OAuth2 for iOS [1]. I still need some cleaning/refactoring before sending a PR. Following Lucas demo, I've tested it to display a list of your Google Drive files. You can test it here [2]. I will also do a PR for our ios-cookbook to add GoogleDrive app. Note that the implementation is not yet complete, we'll need to add: -revoke -refresh Main difference with js implementation is that I don't store permanently the accessTokens, I prefer to let the application developer decide whether or not the application should save the accessToken. OAuth2 interface is here [3]

Managing OAuth callback into the application was the tricky point for Google+ as iOS implementation is poorly documented (I will add a section on Readme how to configure Google project etc…), Android version should be easier. ++ Corinne [1] https://github.com/corinnekrych/aerogear-ios/tree/AGIOS-138/AeroGear-iOS/... [2] https://github.com/corinnekrych/GoogleDrive [3] https://github.com/corinnekrych/aerogear-ios/blob/AGIOS-138/AeroGear-iOS/... On Dec 19, 2013, at 1:49 PM, Luke Holmquist <lholmqui(a)redhat.com&gt; wrote: > 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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Dec 20, 2013, at 2:28 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > cool > On Dec 20, 2013, at 2:40 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > >> Hello All, >> >> I've implemented OAuth2 for iOS [1]. I still need some cleaning/refactoring before sending a PR. >> Following Lucas demo, I've tested it to display a list of your Google Drive files. You can test it here [2]. I will also do a PR for our ios-cookbook to add GoogleDrive app. >> >> Note that the implementation is not yet complete, we'll need to add: >> -revoke >> -refresh >> >> Main difference with js implementation is that I don't store permanently the accessTokens, I prefer to let the application developer decide whether or not the application should save the accessToken. OAuth2 interface is here [3] > I'm still not sure this is a good idea on my part, it does help if the user refreshes the page, then they still have the token. > > although since the access token does expire, then it might not be to bad it's not a bad idea storing them as they have limited life ( I've read it's more the refresh token you should not store because this one last longer)

but I think this should be left to the developer to decide how he wants to deal with accessToken. Basically does the application prompt the user for authz at each load, or store the access token and prompt when expired etc.. That should be left to the developer. I would rather follow Authentication authToken strategy, we keep them in memory within authModule and pass them to the pipe. wdyt? This part still need work on my side. > >> >> Managing OAuth callback into the application was the tricky point for Google+ as iOS implementation is poorly documented (I will add a section on Readme how to configure Google project etc…), Android version should be easier. >> >> ++ >> Corinne >> [1] https://github.com/corinnekrych/aerogear-ios/tree/AGIOS-138/AeroGear-iOS/... >> [2] https://github.com/corinnekrych/GoogleDrive >> [3] https://github.com/corinnekrych/aerogear-ios/blob/AGIOS-138/AeroGear-iOS/... >> >> On Dec 19, 2013, at 1:49 PM, Luke Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >>> 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 >> >> >> _______________________________________________ >> 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

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