-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reworking the node-oauth2-provider. #31
Comments
I think the future features ammmir described in the README.md sound tasty as well with session managment abstracted too mongoose. I am having a hard time figuring out how to save the access token after a client side password grant POST is made. In my unique use case, I will POST from a client side javascript app username and password too "myapp.com/oauth/access_token" and will be returned an access token in a JSON response (allowing CORS). In the myOAP.on('save_access_token') method I would expect too save the access_token that was just granted with mongoose. Every subsequent request would need to include the access_token as well as the session id to authenticate user request. |
@mrevilme you're welcome to fork if you really like the EventEmitter-style API (i think it sucks). for v2 i'm planning something nicer, while keeping it minimal and connect-compatible: var OAuth2Provider = require('oauth2-provider'),
RedisStore = require('oauth2-provider-redis');
var provider = new OAuth2Provider({
crypt_key: 'alice',
sign_key: 'bob',
authorize_uri: '/oauth/authorize',
access_token_uri: '/oauth/access_token',
store: new RedisStore({url: '...'})
});
provider.createAccessToken(function(user_id, client_id, next) {
...
});
provider.enforceLogin(function(req, res, authorize_url, next) {
...
});
...
// later
app.use(provider.middleware()); where function connect(next);
function lookup_grant(client_id, client_secret, code, next);
function save_grant(user_id, client_id, code, next);
function remove_grant(user_id, client_id, code, next);
function save_access_token({user_id: '...', client_id: '...', access_token: '...'}, next);
... obviously, it should be agnostic and support all of the OAuth2 flows and auth types. sadly, i have no urgency for this, since i'm not working on an OAuth2-heavy project at the moment. @gigablox sounds like the |
@ammmir I am indeed thinking about leveraging the I am backlinking too your library to try to bring in some more people to the discussion :) |
@ammmir Can you explain me what http://localhost:8081/secret is trying to do? How can I connect to my own Authentication server when the client is accessing http://localhost:8081/login |
Im working on extending the feature set of this package to include "client-credentials" authentication.
The problem is that the code package at the moment is very static to always having a "user_id" for every part of the auth process while client-credentials authentication is built for validating a application to do certain actions that doesn't require a user for example registration of users.
So atm im reworking some methods _createAccessToken and the callbacks; create_access_token, save_access_token. Unfortunately these changes will not be backwards compatible.
What i wanted is to start a discussion on if i should break off my fork to totaly different name and start reworking the code so you can keep your code backwards compatible or if we should work together.
Cheers
Emil
The text was updated successfully, but these errors were encountered: