We've got an Angular app that calls APIs with JWT token authentication (so an auth token and a refresh token). Now at some point the user changes his password (while normally logged in, so not with a "reset password" logic when he can't login anymore) so we call /change-password endpoint

Currently we keep the user logged in and keep using the same tokens, but is this acceptable? Shouldn't there be some kind of invalidation?

I understand from the OWASP guidelines that all sessions should get invalidated on this case. So how do we manage that with JWT tokens?

  • Why not invalidate the tokens when the user is changing his password?
    – defalt
    Commented Oct 11, 2023 at 18:34

1 Answer 1


That is one of the problems with JWTs: Unless your application is both the issuer of the tokens and the consumer, revoking the token is complicated as it requires communication between consumer and issuer.

This is commonly resolved by having only a very short expiry (minutes) on the access_token and using the refresh_token to obtain new ones.

  • Even if you're both issuer and consumer of the JWT, they can't easily be revoked! Implementing revocation requires a whole additional level of token verification that at least partially loses the statelessness benefit that is one of the main reasons people use JWTs to begin with. This is why it's generally essential to use a refresh token (which is stored server-side, and thus easy to revoke) and keep JWT lifetimes really short, often single-digit minutes.
    – CBHacking
    Commented Oct 12, 2023 at 2:00
  • Ok so you are saying it's acceptable to maintain the access_token until it needs to be refreshed? (our access_token is indeed short lived, only 5mins I think) And revoking the refresh_token at this point would require re-auth when the token needs to be refreshed, right? Commented Oct 13, 2023 at 8:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .