[aerogear-dev] OAuth2 Adapter

[Bruno Oliveira]

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