Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Authentication next #1045
I wrote about this a little already in the Feathers Crow roadmap update. This issue is meant to collect all related issues that the next version of Feathers authentication will cover.
With the current (Buzzard) release, Feathers core became fully framework independent, however, the authentication plugin is still registering some Express middleware. In the next version that middleware will move into @feathersjs/express and make authentication core also framework independent. This will allow new transports like Koa or MQTT.
Improved socket authentication
Currently, websockets are authenticated and logged out through a custom event mechanism. This was causing some issues (e.g. infrequent “No auth token” errors), especially around reliable reconnection on both sides, the server and the client.
Improved authentication client
This will remove dependence on the stateful access token and gracefully handle socket re-authentication.
No more cookies, improved oAuth
Better option handling
All authentication settings will now be evaluated at runtime so it is possible to set them dynamically and there will be no errors for options that are not required. It will also allow to pass a custom authentication service.
Refresh tokens and blacklisting
Instead of allowing refreshing with the existing JWT the standard authentication service will now also return a longer lived refresh token. Token blacklisting still needs to be implemented manually but will be easier to integrate through the methods in the new authentication service.
This discussion started in #844 and in #844 (comment) summarizes the points why this is happening. In short, there has not been much development in PassportJS especially around supporting frameworks other than Express and most other HTTP frameworks like Koa or Hapi moved on to use more flexible and minimalist authentication libraries (like https://github.com/simov/grant for oAuth). It also turned out that there are only four types of strategies that are really needed:
Without having to work around Passport, Feathers can easily sit on top of any HTTP library and any other transport mechanism (like MQTT or even P2P connections) with a clear separation of concerns and provide an authentication mechanism that is much easier to understand and customize.
This only applies to the server and is what implicitly happens already through
Usability wise nothing will really change for external or internal calls but if you now want to trigger the
The authentication client will still make authenticated requests once it has been logged in by calling
Will definitely put the information about prereleases here. Just wrapping up the authentication client which should handle authenticated websockets much more reliably. Once that is done it would be great to have some help testing the new core + local and jwt authentication. oAuth should be soon to follow after that.
You can see the current progress in the master branch and I will put out a blog post when beta testers can try it out. The status is:
Hi, this is great!
Future flexibility is cool, but I don't have confidence with auth in my FeathersJS project yet and I'm going through a confusing process to create that.
Having a complete, tested, and secure auth implementation means I can confidently move on to features. One of the best reasons to use MeteorJS was it's excellent accounts integration all the way to the client.
Looking through FeatherJS issues, many are about authentication, so I'm excited for this work to land!
Where is the best documentation (or reference implementation) for a complete secure auth system (local auth, access control, emails, etc) in FeathersJS today?
This is what I have so far - is there anything better?
2018/02 - Setting up email verification in FeathersJS (rehash of 2017 article)
Thanks in advance!