How to update jwt correctly?

Question

PHP

I want to figure out how to correctly implement a jwt update for a web application.
By googling, I found the answer stackoverflow.com/questions/26739167/jwt-json-web-...
But as I understand it, they suggest storing in the token itself the time when the current token needs to be blocked and a new one needs to be issued.
Those. it turns out that if the token is stolen, then it can be used indefinitely. if there is a token and the refresh time expires, a new valid token is issued. Or do we ignore the problem of token theft, hoping for HTTPS?
I also came across a scheme with jwt and a refresh token, like a new jwt can only be obtained if you present a refresh token. In such a scheme, I saw the following situation:
1. The client makes a request to the server by sending an already expired jwt
2. The server returns 401/403
3. To prevent the end user from being authenticated again, the client catches this 401/403 error and makes a request for a new jwt by presenting a refresh
4. The server issues a new jwt (and possibly plus a new refresh token as well) and the client repeats request #1 but with a valid jwt and everyone is almost happy.
For the end user, such a scheme will most likely look like a long page load.
In the end, how to properly update jwt so that it is safe and the end user is satisfied?

Answer 1

cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt...
TL;DR Sessions are everything

Answer 2

The token should have a short lifetime, for example 60 minutes. After the token expires, you have 2 choices:
1. Log in again using your login password and get a new token for 60 minutes. In this case, the lifetime of the token is minimal and you don't have to worry about stealing it. Authorization takes place once an hour, which complicates the theft of the password, but if it is stolen, then the life of the token is scanty.
2. Use the method of refreshing an expired token. At the same time, such an opportunity should be limited by time, for example, a maximum of 14 days after the expiration of the existing token.
The ability to exit the session with blacklisting the current still valid token. It can be stored directly in the cache and deleted when its lifetime expires.
For myself, I chose the first option with the ability to exit the session for special paranoids. If the current token is stolen, then the client changes the password, and its issued token is blacklisted. After 60 minutes, we can assume that we have protected the client. But I didn’t do a refresh, because in case of theft, I might not keep track of the issued or updated tokens.