error always null when using custom callback about passport-jwt HOT 6 CLOSED

This was pretty confusing for me. If an expired or invalid token is not an exception, what is?

Here's the middleware I ended up with.

function authenticate() {
  return (req, res, next) => {
    passport.authenticate('jwt', (err, data, info) => {
      if (err || info) {
        next(new Error('Unauthorized.'));
      } else {
        next();
      }
    })(req, res, next);
  };
}

from passport-jwt.

@LukeAskew I wrote this module using passport-local as a model.

In passport-local, which was written by the author of the passport framework, failure to authenticate is not treated as an exception. Instead, invalid credentials results in the strategy calling self.fail() (which populates info). I treat expired or invalid JWT's the same way the passport-local strategy would treat an incorrect password or a non-existent user.

Based on my understanding of passport-local, only things like database errors, etc. result in exceptions. To me this makes sense since exceptions should be reserved for unexpected errors. Invalid auth credentials are an expected case for an authentication framework and not treated as an exception by this module or passport-local.

from passport-jwt.

Marking as help wanted to encourage others to look at this and weigh in.

from passport-jwt.

This issue makes this lib completely unusable for anything more advanced/custom than basic examples.
Nothing in the documentation explains how to actually handle each error case either.
It was a very frustrating experience getting to this specific issue on github, just to see that its not considered a thing.

from passport-jwt.

From the Custom Callback documentation:

If authentication failed, user will be set to false. If an exception occurred, err will be set. An optional info argument will be passed, containing additional details provided by the strategy's verify callback.

err should only be non-null when an exception occurs. Currently this library does not treat malformed JWT's or expired JWT's as exceptions, just failed authentication attempts.

While I could see the reasoning for treating a malformed JWT as an exception while maintaining the current behavior for expired JWT's I don't know that it would be worth breaking compatibility for callers that expect the info object to be populated.

I'm going to mark this as won't fix for now but leave it open to see if we get any consensus around one behavior or another.

from passport-jwt.

Closing since i haven't heard anything in nearly a year.

from passport-jwt.