that hopefully shows the flow a bit
On Aug 29, 2013, at 2:05 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
i did get it to work
On Aug 29, 2013, at 2:04 PM, Sebastien Blanc <scm.blanc(a)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(a)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(a)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(a)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(a)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(a)abstractj.org>
wrote:
>>>>
>>>>> +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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev(a)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
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)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
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev