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

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 :)

Answer 2

There is no way I know of to arbitrarily invalidate a token without involving a database one way or another.

Be careful with Approach 2 if your service can be accessed on several devices. Consider the following scenario...

• User signs in with iPad, Token 1 issued and stored.
• User signs in on website. Token 2 issued. User logs out.
• User tries to use iPad, Token 1 was issued before user logged out from website, Token 1 now considered invalid.

You might want to look at the idea of refresh tokens although these require database storage too.

Also see here for a good SO discussion regarding a similar problem, particular IanB's solution which would save some db calls.

Proposed solution Personally, this is how I'd approach it...user authenticates, issued with access token with a short expiry (say 15 mins) and a refresh token valid either for a much longer period or indefinitely. Store a record of this refresh token in a db.

Whenever the user is 'active', issue a new auth token each time (valid for 15 mins each time). If the user is not active for over 15 minutes and then makes a request (so uses an expired jwt), check the validity of the refresh token. If it's valid (including db check) then issue a new auth token.

If a user 'logs out' either on a device or through a website then destroy both access refresh tokens client side and importantly revoke the validity of the refresh token used. If a user changes their password on any device, then revoke all their refresh tokens forcing them to log in again as soon as their access token expires. This does leave a 'window of uncertainty' but that's unavoidable without hitting a db every time.

Using this approach also opens up the possibility of users being able to 'revoke' access to specific devices if required as seen with many major web apps.

Answer 3

I am not sure if I'm missing something here but I find that the accepted answer is more complicated than is necessary.

I see that db has to be hit to validate or invalidate a token for each api request, however the total process could have been simpler as I see things here.

Whenever a jwt is created, i.e. during login or change/reset password, insert the jwt with userid into a table and maintain a jti (a uuid number basically) for each jwt. The same jti goes into jwt payload too. Effectively jti uniquely identifies a jwt. A user can have multiple jwts at the same time when the account is accessed from multiple devices or browsers in which case, jti differentiates the device or the user-agent.

So the table schema would be, jti | userId. (and a primary key ofcourse)

For each api, check if the jti is in the table, which means the jwt is a valid one.

When the user changes or resets the password, delete all the jti of that userId from the db. Create and insert a new jwt with a new jti into the table. This will invalidate all the sessions from all other devices and browsers except the one that changed or reset the password.

When the user logsout, delete that particular jti of that user but not all. There would be a Single Login but not a single Logout. So when the user logs out, he shouldnt be logged out from all the devices. However, deleting all the jtis would logout from all the devices too.

So it would be one table and no date comparisons. Also it would be the same case if a refresh token is used or not.

However to minimize the db interference, and possible delays, cache usage would certainly help to ease things on processing time front.

Note: Please reason if you are down voting it.

Answer 4

If a user is changing their password, you're going to hit the db there. But don't want to hit the db for authorization?

I have found the benefits of storing a per user string, and a global shared string hashed together gives us the most flexibility with our JWT implementation. In this particular case I'd store a hash of the password to use with the global string and hash them together for a JWT secret.

Answer 5

I agree solely with @gopinath answer just want to add one thing that you should also remove the change password time when all of your tokens expired for example suppose you have set 3 day expiry time for every token to expire now instead of just normaly saving change password time in database you can also set its expiry time of 3 days because as obviously tokens before this will be expired so no need to check for every token again that whether its expiry time is greater then change password time or not