[aerogear-dev] OAuth2 Adapter

[Kris Borchers]

On Aug 27, 2013, at 6:04 AM, Lucas Holmquist <lholmqui at redhat.com> wrote:

> 
> On Aug 27, 2013, at 3: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 ?
> 
> 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 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/00b39450/attachment.html