-
-
Notifications
You must be signed in to change notification settings - Fork 751
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
Comments
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
}
} |
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. |
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 |
From @andysay on April 15, 2018 8:14 nice! |
From @ydeshayes on April 15, 2018 13:13 Do the token expire date is renewed in this case? |
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. |
From @m0dch3n on April 11, 2018 10:30
If you do
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
The text was updated successfully, but these errors were encountered: