[aerogear-dev] OAuth2 Adapter
Sebastien Blanc
scm.blanc at gmail.com
Thu Aug 29 14:04:11 EDT 2013
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
> pipesFirst 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 <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 <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 <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<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<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<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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20130829/58806df3/attachment-0001.html
More information about the aerogear-dev
mailing list