Server Side
Client Side
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
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
}
});
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?
}
});
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"
+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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev