[aerogear-dev] OAuth2 Adapter
Luke Holmquist
lholmqui at redhat.com
Thu Dec 19 07:49:51 EST 2013
https://github.com/aerogear/aerogear-js/pull/58
I reopened it
Sent from my iPhone
> On Dec 19, 2013, at 6:08 AM, Bruno Oliveira <bruno at abstractj.org> wrote:
>
> Do we have a PR for it? Works like a charm on chrome, didn’t went well for safari. But let’s start simple, attach a PR please, I’m anxious to test it.
>
> --
> abstractj
>
>> On December 19, 2013 at 6:45:14 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote:
>>
>> I just tested the demo, very cool, work as advertised ;)
>>
>>
>>> On Wed, Dec 18, 2013 at 8:45 PM, Lucas Holmquist 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
>>> wrote:
>>>
>>> i did get it to work
>>>> On Aug 29, 2013, at 2:04 PM, Sebastien Blanc
>>> wrote:
>>>
>>> This update is really cool, is the pipe test flow working ?
>>>
>>>
>>>> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist 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
>>>> 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
>> 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
>> 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
>> wrote:
>>>>
>>>> +1 keep it simple, please
>>>>
>>>> Lucas Holmquist wrote:
>>>>
>>>>
>>>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc > >> >>
>> 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 > >> >>
>> 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
>>>> /
>>>>
>>>> /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 > >> >>
>> 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
>>>> 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
>>>>
>>>>
>>>> --
>>>> 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
>> _______________________________________________
>> 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