Best practices to invalidate JWT while changing passwords and logout in node.js?

Question

I would like to know the best practices to invalidate JWT without hitting db while changing password/logout.

I have the idea below to handle above 2 cases by hitting the user database.

1.Incase of password changes, I check for password(hashed) stored in the user db.

2.Incase of logout, I save last-logout time in user db, hence by comparing the token created time and logout time, I can able to invalidate this case.

But these 2 cases comes at the cost of hitting user db everytime when the user hits the api. Any best practise is appreciated.

UPDATE: I dont think we can able to invalidate JWT without hitting db. So I came up with a solution. I have posted my answer, if you have any concern, you are welcome.

Answer 1

When No Refresh token is used:

1.While changing password: when the user changes his password, note the change password time in the user db, so when the change password time is greater than the token creation time, then token is not valid. Hence the remaining session will get logged out soon.

2.When User logs out: When the user logs out, save the token in a seperate DB (say: InvalidTokenDB and remove the token from Db when token expires). Hence user logs out from the respective device, his sessions in other device left undisturbed.

Hence while invalidating a JWT, I follow the below steps:

1. Check whether the token is valid or not.
2. If valid, check it is present in invalidTokenDB (a database where logged out tokens are stored till their expiry time).
3. If its not present, then check the token created time and changed password time in user db.
4. If changed password time < token created time, then token is valid.

Concern with the above method:

1. For each api request, I need to follow all the above steps, which might affect performance.

When Refresh token is used: with expiry of access token as 1 day, refresh token as lifetime validity

1. While changing password: When the user changes his password, change the refresh token of the user. Hence the remaining session will get logged out soon.

2. When User logs out: When the user logs out, save the token in a seperate DB (say: InvalidTokenDB and remove the token from Db when token expires). Hence user logs out from the respective device, his sessions in other device left undisturbed.

Hence while invalidating a JWT, I follow the below steps:

1. check whether the token is valid or not
2. If valid, check whether the token is present in InvalidTokenDB.
3. If not present, check the refresh token with the refresh token in userDB.
4. If equals, then its a valid token

Concern with the above method:

1. For each api request, I need to follow all the above steps, which might affect performance.
2. How do I invalidate the refresh token, as refresh token has no validity, if its used by hacker, still the authentication is valid one, request will be success always.

Note: Although Hanz suggested a way to secure refresh token in Using Refesh Token in Token-based Authentication is secured? , I couldn't able to understand what he is saying. Any help is appreciated.

So If anyone have nice suggestion, your comments are welcome.

UPDATE: I am adding the answer incase your app needs no refresh token with lifetime expiry. This answer was given by Sudhanshu (https://stackoverflow.com/users/4062630/sudhanshu-gaur). Thanks Sudhanshu. So I believe this is the best way to do this,

When No Refresh token needed and no expiry of access tokens:

when user login, create a login token in his user database with no expiry time.

Hence while invalidating a JWT, follow the below steps,

1. retrieve the user info and Check whether the token is in his User database. If so allow.
2. When user logs out, remove only this token from his user database.
3. When user changes his password, remove all tokens from his user database and ask him to login again.

So with this approach, you don't need to store neither logout tokens in database until their expiry nor storing token creation time while changing password which was needed in the above cases. However I believe this approach only valids if your app has requirements with no refresh token needed and no expiry of the tokens.

If anyone has concern with this approach, please let me know. Your comments are welcome :)