Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

option for non-JWT based session #597

DanielFGray opened this Issue Oct 27, 2017 · 1 comment


None yet
2 participants
Copy link

DanielFGray commented Oct 27, 2017

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



This comment has been minimized.

Copy link

daffl commented Oct 27, 2017

@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: 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 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.