[aerogear-dev] OAuth2 Adapter

Lucas Holmquist lholmqui at redhat.com
Thu Jan 2 08:30:24 EST 2014


On Jan 2, 2014, at 7:59 AM, Karel Piwko <kpiwko at redhat.com> wrote:

> Looks good and works fine with FF24 and Chrome27. I was missing instruction how
> to enable client access in Google Console though, so I added them here: https://github.com/lholmquist/ag-google-drive/pull/1

cool

> 
> Other interesting fact is that FF shows "delete" text while Chrome shows
> wastebin icon, I wasn't looking deeper into that though.
> 
> Karel
> 
> On Wed, 18 Dec 2013 14:45:39 -0500
> Lucas Holmquist <lholmqui at redhat.com> wrote:
> 
>> i've created a new example here, https://github.com/lholmquist/ag-google-drive
>> 
>> that hopefully shows the flow a bit
>> On Aug 29, 2013, at 2:05 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>> 
>>> i did get it to work
>>> On Aug 29, 2013, at 2:04 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>> 
>>>> This update is really cool, is the pipe test flow working ?
>>>> 
>>>> 
>>>> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist <lholmqui at redhat.com>
>>>> wrote: i've updated the sample again
>>>> https://github.com/lholmquist/oauth2test
>>>> 
>>>> this time i added a pipe object and used pipe.read to see how the flow
>>>> would be
>>>> 
>>>> 
>>>> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>> 
>>>>> i've updated the sample app with the new flow
>>>>> 
>>>>> https://github.com/lholmquist/oauth2test
>>>>> 
>>>>> 
>>>>> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>>> 
>>>>>> ok,  Kris had some thoughts on a better flow, so i refactored the code a
>>>>>> bit and i think i like this way a bit better.  
>>>>>> 
>>>>>> New Flow - Client Flow - Standalone for now, possible integration with
>>>>>> pipes
>>>>>> 
>>>>>> First Time - No Access Token stored( in localStorage )
>>>>>> 
>>>>>> User will create the Authorization Object stuff with settings/options
>>>>>> 
>>>>>> var thing = AeroGear.Authorization();
>>>>>> 
>>>>>> thing.add({
>>>>>>    name: "coolThing",
>>>>>>    settings: {
>>>>>>        clientId: "12345.apps.googleusercontent.com",
>>>>>>        redirectURL: "http://localhost:8000/redirector.html",
>>>>>>        tokenValidationEndpoint:
>>>>>> "https://www.googleapis.com/oauth2/v1/tokeninfo", authEndpoint:
>>>>>> "https://accounts.google.com/o/oauth2/auth", revokeURL:
>>>>>> "https://accounts.google.com/o/oauth2/revoke", scopes:
>>>>>> "https://www.googleapis.com/auth/userinfo.profile", prompt: "force"
>>>>>>    }
>>>>>> });
>>>>>> should have the ability to specify more settings, based on the spec
>>>>>> 
>>>>>> The user would then call some method( currently not good names are
>>>>>> coming to me, maybe validate ) that takes success and error callbacks.
>>>>>> 
>>>>>> thing.services.coolThing.validate({
>>>>>>    success: function( response ){
>>>>>>        console.log( "Should be response from Validating the access
>>>>>> token", response ); },
>>>>>>    error: function( error ) {
>>>>>>        //should contain a constructed URL for the user
>>>>>>        console.log( "error", error );
>>>>>>    }
>>>>>> });
>>>>>> Since this is the first time, the error callback will be called and will
>>>>>> contain the constructed URL that the user should do the popup redirect
>>>>>> dance with to get an access token.
>>>>>> 
>>>>>> what "dance" they do is up to the developer
>>>>>> 
>>>>>> Once that happens and they have the access token, they would call the
>>>>>> validate method again.
>>>>>> 
>>>>>> this makes sure that the token they recieved is validated and will also
>>>>>> return some other meta data related to the token, like refresh time.
>>>>>> 
>>>>>> Once the token has been validated, it will be stored in localStorage and
>>>>>> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is .
>>>>>> 
>>>>>> so in this example it would be something like:
>>>>>> 
>>>>>> ag-oauth2-12345.apps.googleusercontent.com
>>>>>> There is one problem i can see here though. If the user has to
>>>>>> applications with the same client ID but different scopes assigned, this
>>>>>> would be a problem. That use case could be considered bad practice anyway
>>>>>> 
>>>>>> The user can then call the "callService"( yes, again, crappy name )
>>>>>> method to get access to the service they want.
>>>>>> 
>>>>>> thing.services.coolThing.callService({
>>>>>>    serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo",
>>>>>>    success: function( response ){
>>>>>>        console.log( "Should be the response from the call", response );
>>>>>>    },
>>>>>>    error: function( error ) {
>>>>>>        console.log( "error", error );
>>>>>>    }
>>>>>> });
>>>>>> All these methods would have success/error callbacks.
>>>>>> 
>>>>>> Token Expiration
>>>>>> 
>>>>>> If the user makes a call to a service, using the callService method, and
>>>>>> they recieve an error such as not authorized or token invalid or token
>>>>>> expired, I'm thinking we send what the "contructed URL" should be,
>>>>>> similar to the validate method described above.
>>>>>> 
>>>>>> Since this is a Client Side flow, there is no refresh token, so the
>>>>>> client wouldn't be able to refresh the access token without doing the
>>>>>> "dance" again.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist <lholmqui at redhat.com> wrote:
>>>>>> 
>>>>>>> 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
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>>>> 
>>>> _______________________________________________
>>>> 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




More information about the aerogear-dev mailing list