feathersjs-ecosystem / authentication-jwt

[MOVED] JWT authentication strategy for feathers-authentication using Passport
https://github.com/feathersjs/feathers
MIT License
30 stars 10 forks source link

Restrict authentication by JWT #61

Closed m0dch3n closed 6 years ago

m0dch3n commented 6 years ago

If you do

app.authenticate({
  strategy: 'jwt',
  accessToken: 'current access token'
});

You get a new access token every time, with new expiresIn etc, so theoretically, you no longer need the users password to know, because you can simply refresh your token before expiration, by this method.

So if a bad guy steals one of my clients jwt, I'm no longer able to block the user account.

If I blacklist the jwt, I need a database lookup. However if the bad guy already refreshed the jwt, I need to know the whole chain, to block every jwt he generated, so I can't simply block the first stolen jwt...

So I can't blacklist him, nor will the jwt ever expire. The only solution would be, to change my servers secret, however, this would invalidate ALL my others client's session.

So should authentication by jwt not simply verify and return the original jwt, and not generate a new one everyone ?

m0dch3n commented 6 years ago

Here is a hook, I currently created, to solve the problem

const {checkContext} = require('feathers-hooks-common');

module.exports = function () {
  return async context => {
    checkContext(context, 'after', ['create', 'update', 'patch'], 'jwtAuthentication')
    if (context.path === 'authentication' && context.data && context.data.strategy === 'jwt') {
      context.result.accessToken = context.data.accessToken
    }
    return context
  }
}
daffl commented 6 years ago

I was under the impression that JWT auth will just verify and return the existing token but it appears that it creates a new one, so you are correct. Your hook is definitely the way to go at the moment, I created a similar fix in https://github.com/feathersjs/authentication/pull/664. Unfortunately it will probably have to be a major release since people probably depend on this behaviour.

I am also working on a new version of the authentication library that will be framework independent, support refresh tokens and blacklisting and not have this issue.

m0dch3n commented 6 years ago

Ok, that would be great!

That would also close the issue which I referenced above.

I said also a few words about an access/refresh pattern there :

https://github.com/feathersjs/authentication/issues/22#issuecomment-380859393

andysay commented 6 years ago

nice!

ydeshayes commented 6 years ago

Do the token expire date is renewed in this case?

daffl commented 6 years ago

This issue was moved to feathersjs/feathers#960