option for non-JWT based session

[DanielFGray]

I know it's probably a big change to the code base, but perhaps it could be modularized so other types can be used.

Motivation: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

[daffl]

@ekryski addressed some of those concerns already in an email before (glad I remembered where it was 😄) so I'll share it here:

This article is lengthy and brings up valid concerns. We’re well aware of all the issues the author brings up. In some cases we disagree but overall they are mostly correct and we’ve mitigated those concerns with the exception that revoking a token is left up to the developer. I can’t cover everything in the article but the key things you need to ensure are outlined in here: https://docs.feathersjs.com/SECURITY.html#security-considerations as well as:

• By default the only thing that Feathers stored in the JWT payload is the user id. It is a stateful token. You can change this and make the token stateless by putting more data into the JWT payload but this is at your discretion. Currently the user is looked up on every request after the JWT is verified to not be expired or tampered with.

• You need to make sure that you revoke JWT tokens or set a low expiration date or add custom logic to verify that a user’s account is still valid/active. Currently the default expiration is 1 day. We chose a reasonable default for most apps but depending on your application this might be too long or too short.

Much of that article is an opinion piece and not filled with a ton of facts. However, if you don’t feel comfortable with using JWTs than feathers-authentication may not be for you. That is okay, you can still use regular express session middleware. Lots of guides on how to do that.

As for having to use JavaScript on the client, this is indeed true but Feathers is primarily intended as an API framework and it might make sense to consider other alternative for purely server rendered pages.

Again, as @ekryski already said, you are still always open to implement the regular Express session based way (the deprecated https://github.com/feathersjs-ecosystem/feathers-passport did that if you are looking for a place to start) to secure your REST API on top of Feathers but once websockets come into play you'll probably have to go through a lot of the pains we already had to solve when developing feathers-authentication.