Reworking the node-oauth2-provider.

[emil-palm]

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

[gigablox]

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.

[ammmir]

@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 store is an object that implements a simple protocol (just brainstorming here), obviating the need to customize the provider too much.

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 token response_type would work best for you.

[gigablox]

@ammmir I am indeed thinking about leveraging the token response_type for my unique case. However, we are no longer using a client_id & client_secret when talking about a pure client-side app. I go into detail about in this stackoverflow post which has recieved a lot of attention:

http://stackoverflow.com/questions/15286324/authenticate-client-side-app-to-rest-api-with-local-strategy

I am backlinking too your library to try to bring in some more people to the discussion :)

[user1702]

@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