af83

OAuth2 server, OAuth2 resource server and OAuth2 client in Node

Today, AF83 has released three new Open Source (AGPL) projects on GitHub:

There are all about the OAuth2 protocol (draft 10 of the specification to be more specific). New branches will be created for the draft 11 of the specification, released on December 1.

OAuth2_{client,server}_node

The two first projects are two Connect middlewares and provide bases to easily implement an OAuth2 client and an OAuth2 server (+ resources server possibly). They only implement the web server profile, but try to do it well. That doesn't mean there is no errors in the implementation though, and bugs fixes / reports are more than welcome.

auth_server

auth_server uses the oauth2_{client,server}_node projects (+ mongoDB and others) and provides an authentication and authorizations provider.

It is still alpha software, but the goal is to have an interface to be able to specify, for a given email, application and context, a list of roles: {application, context, email, [roles]}.

  • For example, I want to let the user Alice have the role "admin" on the application "trac" inside the context "af83-rd" ({'trac', 'af83-rd', 'alice@af83.com', ['admin']}).

    • When logging to "trac", Alice is redirected to auth_server, in which she signs in using her email/password.
    • Alice is then redirected to the application "trac" with a token.
    • Using this token, trac can ask auth_server what roles Alice have.
    • Alice can now administer the "af83-rd" part of the "trac" application. Specifying {'trac', '*', '*@af83.com', ['user']} will enable every person @ af83 to be user on trac.

The benefits are multiple:

  • there is only one application where Alice has to be registered (and so one set of credentials per user);
  • when developing a new application, there is no need to recreate all user registration process stuff, but only to plug the application to auth_server;
  • all the authorizations can be managed in a central place.

Of course (to do things well), auth_server is plugged to itself: setting {'auth_server', 'trac', 'bob@af83.com', ['admin']} should enable Bob to administer the authorizations for the application 'trac' on auth_server.

auth_server is usable (ie: users can sign in/out the the application and others applications using the service), but the administration interface lacks many features, including adding/editing authorizations. The asterisks part described above is not implemented yet.

Participations are welcome!

Pierre

blog comments powered by Disqus