[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