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

Restrict authentication by JWT #960

Closed
daffl opened this issue Aug 29, 2018 · 6 comments
Closed

Restrict authentication by JWT #960

daffl opened this issue Aug 29, 2018 · 6 comments

Comments

@daffl
Copy link
Member

daffl commented Aug 29, 2018

From @m0dch3n on April 11, 2018 10:30

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 ?

Copied from original issue: feathersjs-ecosystem/authentication-jwt#61

@daffl
Copy link
Member Author

daffl commented Aug 29, 2018

From @m0dch3n on April 12, 2018 8:57

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
Copy link
Member Author

daffl commented Aug 29, 2018

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 feathersjs-ecosystem/authentication#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.

@daffl
Copy link
Member Author

daffl commented Aug 29, 2018

From @m0dch3n on April 13, 2018 5:9

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

@daffl
Copy link
Member Author

daffl commented Aug 29, 2018

From @andysay on April 15, 2018 8:14

nice!

@daffl
Copy link
Member Author

daffl commented Aug 29, 2018

From @ydeshayes on April 15, 2018 13:13

Do the token expire date is renewed in this case?

@daffl
Copy link
Member Author

daffl commented Jun 6, 2019

This has been addressed in v4 authentication which returns the existing JWT instead of creating a new on. See the Migration guide for more information on how to upgrade.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant