+1 keep it simple, please

Lucas Holmquist wrote:

On Aug 27, 2013, at 3:39 AM, Sebastien Blanc <scm.blanc@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@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@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@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
   https://lists.jboss.org/mailman/listinfo/aerogear-dev

   _______________________________________________
   aerogear-dev mailing list
   aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
   https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--
abstractj


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev