[aerogear-dev] OAuth2 Adapter

Sebastien Blanc scm.blanc at gmail.com
Tue Aug 27 04:10:07 EDT 2013


On Tue, Aug 27, 2013 at 9:56 AM, Corinne Krych <corinnekrych at gmail.com>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 at 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 ?
> > Seb
> >
> >
> >
> > On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist <lholmqui at redhat.com>
> 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 at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130827/913d0d6c/attachment-0001.html 


More information about the aerogear-dev mailing list