There is a case when a specific authorized user changes his password or email. As email or password is part of user authentication, I think that it is necessary to revoke all auth tokens
But, how to best practice to refresh auth token in this case?
Access tokens should be refreshed frequently in general.
With traditional sessions, everytime a user makes a request to your app and sends his sessionId via cookie or http-header, you check the session if it is still valid (get the session by its id from the database or memory and check if the "active"-column is "true"). In addition, you can invalidate the session on your server everytime you want (set the "active"-column of this particular session to "false"). For example when the users account gets compromised, you can invalidate all active sessions associated to this specific user.
With access tokens, this can't be done this way, because you don't have a session on the server. The server just gets the access token, checks its signature and the expiration date, and thats it. Lets assume your access token has an expiration time of 24 hours. When an active user gets compromised, you are not able to invalidate his "sessions", because there are none. There are just a bunch of access tokens in the wild which where issued for this user (at a time when the users account was not compromised yet). So you have an app with an compromised user and a number of valid access tokens associated with this particular user wich are valid for the next 24 hours - good luck! I'm curious about how far the hacker gets in this 24 hours.
So what you typically want to do is refresh the token frequently. How to implement this in detail depends heavily on your use case and can't be answered in a general manner. Maybe you can check out the OAuth2 protocol which introcudes the refresh token. In short, a refresh token can issue new access token for a specific user. That way, you can achive short expiration times for your access token without annoying the user with a re-authentication process.
For your specific case, I would say that you can't handle the "event" when a user has changed his password. A user issues an access token - at this moment, the token gets created and is valid until the expiration time has come. What happens until this moment doesn't matter.