[aerogear-dev] OAuth2 Adapter

[Lucas Holmquist]

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 at abstractj.org> wrote:

> +1 keep it simple, please
> 
> Lucas Holmquist wrote:
>> 
>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc <scm.blanc at gmail.com
>> <mailto: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 )
>> 
>> 
>> 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
>>> <mailto:lholmqui at 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 at abstractj.org
>>>    <mailto: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 <mailto:aerogear-dev at lists.jboss.org>
>>>>    https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> 
>>>    _______________________________________________
>>>    aerogear-dev mailing list
>>>    aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>>    https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org <mailto: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
> 
> -- 
> abstractj
> 
> 
> _______________________________________________
> 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/25ceb677/attachment.html