Jwt-auth: How to invalidate existing token on password change?

Created on 24 Jul 2017  路  9Comments  路  Source: tymondesigns/jwt-auth

If user updates the password, the JWT token continues to work. How can we stop accepting that token and asking for login again?

Most helpful comment

What @johannesschobel says will only invalidate the token that was used for the password change request. If the user has multiple tokens, the others will not be invalidated.

You have two options to invalidate all tokens of a particular user:

  1. Keep a list (in the database, using a Cache provider, etc) of all tokens. This is probably the easiest way to do it (I had to do this for one project), but it kind-of defeats the whole "sessionless" purpose of JWT.
  2. Store the timestamp of when the user's password was last changed. When the user uses a token, compare the iat field of the token with the timestamp of the password change. If the iat is before the password change, blacklist the token and log the user out.

All 9 comments

you may need to manually invalidate the token in your updatePassword()..
Try Manager::invalidate(Token $token) (see here)

@johannesschobel Thanks for the tip!

Just curious to know, how does invalidation works in this case? I don't think we store the generated token anywhere, do we?

They are stored in the /storage folder, I think. However, the token itself is "blacklisted" (i.e., it cannot be used any more to authenticate).
Cheers

What @johannesschobel says will only invalidate the token that was used for the password change request. If the user has multiple tokens, the others will not be invalidated.

You have two options to invalidate all tokens of a particular user:

  1. Keep a list (in the database, using a Cache provider, etc) of all tokens. This is probably the easiest way to do it (I had to do this for one project), but it kind-of defeats the whole "sessionless" purpose of JWT.
  2. Store the timestamp of when the user's password was last changed. When the user uses a token, compare the iat field of the token with the timestamp of the password change. If the iat is before the password change, blacklist the token and log the user out.

i assume your route is protected by token to change the password. if it is why don't you just get the header authorization and use that to pass it to invalidate token function?

@hazaveh I think by comparing the iat you will be able to logout all devices, while what you're proposing isn't capable of logging every devices out but just that particular token that was passed along to the protected route.

what about saving the last few digits of the hashed password in the token and checking this when checking the token?

I would store when the password was last updated on your user and then include as hash of this as a custom claim in your token.

When validating your token, check the password last updated hash matches when the password was last updated.

Is just an idea.

You can sign the token with the password haH, then any old token will be invalid

Was this page helpful?
0 / 5 - 0 ratings

Related issues

heroghost picture heroghost  路  3Comments

agneshoving picture agneshoving  路  3Comments

gamelife1314 picture gamelife1314  路  3Comments

therealmjk picture therealmjk  路  3Comments

phamduong picture phamduong  路  3Comments