[aerogear-dev] OAuth2 Adapter
Sebastien Blanc
scm.blanc at gmail.com
Thu Dec 19 03:44:54 EST 2013
I just tested the demo, very cool, work as advertised ;)
On Wed, Dec 18, 2013 at 8:45 PM, 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 <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
>>
>
> _______________________________________________
> 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/20131219/4d7746f4/attachment-0001.html
More information about the aerogear-dev
mailing list