11:42 a.m.
+1 keep it simple, please
Lucas Holmquist wrote:
On Aug 27, 2013, at 3:39 AM, Sebastien Blanc <scm.blanc(a)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(a)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(a)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(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj