Feathers: Deprecate Passport JS?

This is actually good timing because I started looking into more framework independent ways for doing authentication. I'd be ok with only supporting oAuth if you are using Feathers with an Express, Koa or Hapi transport.

Unfortunately this might mean pretty significant breaking changes which is risky given that authentication seems to be the most challenging part of Feathers to people.

This lib could help:
https://github.com/ianstormtaylor/permit

Passport's big selling point is its ecosystem (also true for Express in general because Passport is an important part of its ecosystem). Grant is most viable alternative to Passport, yet it's not nearly as developed as Passport and lacks features (bye, passport-local).
I suppose that investment into framework (agnostic) adapters for Passport is messy but only way to not break things. There were some initiatives but all of them are abandoned, like https://github.com/hapijs/travelogue

The reason is probably that it is not worth the effort. The problem with PassportJS is that

1) By now Passport core (2 releases in the past three years) and most plugins seem to be largely unmaintained
2) Less activity can also mean it is more stable but judging by most issues staying open completely unacknowledged I'm assuming 1)
3) It does not work well with other frameworks
4) It does work even less well with Websockets
5) Very likely even less so with HTTP2 or completely non-HTTP transport protocols (which Feathers can support)

And ultimately especially for Feathers which tries to enforce a protocol independent architecture it doesn't really do much. Right now we are basically converting

Feathers protocol independent format -> Passport friendly (HTTP like) format -> Passport strategy -> Custom code in passport strategy -> Strategy return value -> Feathers format

Where what we really just want do do is

Feathers protocol independent format -> Custom verification code -> Feathers format

All something like passport-local really does is compare a username and password (which you have to do in your own handler anyway) so why not just stick it in a hook?

The biggest challenge is always oAuth which luckily is a standard so it is possible for better alternatives to exist. In reality, Feathers itself shouldn't really have to worry that much about oAuth other than allowing to turn an oAuth access token into a valid JWT. Everything else can (and probably should) be done with whatever framework you end up using Feathers with.

The points seem to be valid. @daffl, what do you think about keeping the compatibility with current Password-based auth modules only for Express (and possibly Koa) engine within this architecture?

If a framework loses the compatibility with Passport and a developer still needs it for its strategies, implementing raw Passport to integrate it similarly to how it's done now won't be a trivial task. Current feathers-auth-* packages contain a plenty of tested and useful boilerplate code for error handling, etc.

A big deal for me (and I think I'm not alone) is that Feathers is Express on steroids that finally feels like a framework with conventions, a bunch of essential features and ability to use existing Express ecosystem, including Passport. I consider this a very strong side of Feathers, it would be a pity if it would require too much efforts to migrate a project to next major framework release and deal with degraded features.

Well, when Feathers changed to become framework independent it didn't loose the support for Express, so it's a similar idea. To move this forward and really support other frameworks and protocols, there unfortunately isn't really a way around doing a similar thing for authentication. The high level APIs will stay roughly the same but internals will change to be more flexible.

I have a feeling that there isn't really much use being made of Passport strategies other than the ones that are supported (and abstracted) by Feathers plugins already anyway (actually I know of several that don't even work - especially through websockets). There aren't really that many authentication use cases for most APIs:

• JWT (+ refresh token)
• Username/password
• Other token (e.g. API key, oAuth accessToken)

This is one of the problems we have at the moment. Most of Feathers open issues and all the mucking around with cookies, sessions, redirects and the authentication client is mostly because of Passport and oAuth when all Feathers really needs is an access token. A better separation would make things more clear and easier to customize.

All of this probably wouldn't even cause as many problems if PassportJS was more actively maintained. Supporting other frameworks seems like a pretty essential feature for a generic authentication layer to me but it looks like all newer frameworks ended up with a more modular (and minimalistic) authentication mechanism on their own.

authentication seems to be the most challenging part of Feathers to people.

I'd like to echo this sentiment. One of the major reason why I decided to try feathers (as a beginner) is that it is one of the only api frameworks which even has a decent auth tutorial. I also think going for feather's own auth implementation is probably the best way to go and will likely make it easier for people like me to work with feathers.

While making changes to the authentication system, I'd strongly recommend switching to regular cookie sessions as the default, with JWT only as a backwards support option.

JWTs are not designed to be used for session-like authentication, and do not offer any meaningful advantages over regular cookie sessions, while cookie sessions offer significant advantages over JWTs (including session hijacking protection, which JWTs are vulnerable to).

This talk does an excellent job explaining why (and how JWTs got popular in the first place): https://youtu.be/GrLtOjCTB1s?t=16m58s

This article is another good reference: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

Feathers isn't using JWT for sessions and and we already addressed most of the concerns brought up in that article in https://github.com/feathersjs/authentication/issues/597#issuecomment-339846437. A large portion of open Feathers issues are not around problems with JWT but with actually using cookies.

There are many very good reasons why we chose JWT. The most important is that Feathers is designed to support non HTTP transport mechanisms. Anybody who has ever tried shoehorning websocket connections into session cookies probably knows what I mean and it isn't even possible at all with other transports (like the planned MQTT) all of which work well with JWT. As I also always point out, it is fairly straightforward to implement your own Express middleware based authentication mechanism for Feathers if that is something that you really want:

app.use(function(req,res, next) {
  // Set service call `param.user` from `session.user`
  req.feathers.user = req.session.user;
});

Thanks for the link out to the autht repo. I failed to additionally search there as well as here for sessions related issues.

I've never heard of websockets having an issue with using cookies, to my knowledge they work fine. For non-http requests, the same token used for the cookie can be given as login token. This makes http-based requests more secure (and standard) by default, and is just as simple to implement for other services. It also solves being able to revoke tokens, since now you can very easily (and also clear all open sessions for a password reset or manual "logout all", etc).

Ideally, if you do stick with JWTs, you should have docs page outlining the full reasoning behind the decision, and including all concerns brought up about them, and why they don't apply, or why the tradeoff decision was made.

Feathers v4 authentication is completely framework independent and no longer relies on PassportJS. If allows to use custom access tokens if you are not a fan of JWT and uses Grant for oAuth (which makes things a lot easier). See the Migration guide for more information on how to upgrade.