[aerogear-dev] OAuth2 Adapter

[Bruno Oliveira]

+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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130827/e1e41816/attachment.bin