I want to figure out how to properly implement the update jwt for web - applications.

By googling I found the answer https://stackoverflow.com/questions/26739167/jwt-json-web-token-automatic-prolongation-of-expiration . But as I understand there they offer to store in the token itself the time when the current token needs to be blocked and issued a new one. Those. it turns out that if the token is stolen, then it can be used indefinitely since if there is a token and the update time expires, a new valid token is issued. Or we hammer on a problem of theft of a token, hoping for HTTPS?

Still came across a scheme with jwt and refresh tokens, such as the new jwt can only be obtained if you present a refresh token. In this scheme, I saw the following situation:

  1. The client makes a request to the server passing already expired jwt
  2. The server gives 401/403
  3. To prevent the end user from authenticating again, the client catches this 401/403 error and makes a request for a new jwt presenting a refresh
  4. The server issues a new jwt (and possibly plus a new refresh token yet) and the client repeats request # 1, but with a valid jwt and everyone is almost happy.

For the end user, such a scheme is likely to look like a long page load.

In summary, how to update jwt correctly so that it is safe and the end user is satisfied?

    2 answers 2

    Use the refresh token, but set the time interval to fade jwt in which the client application must request a new jwt in advance, without waiting for its expiration date. If the user has not entered the application for a long time and the token is still rotten - well, nothing, wait a few fractions of a second as an exception.

      Those. it turns out that if the token is stolen, then it can be used indefinitely since if there is a token and the update time expires, a new valid token is issued.

      He himself now thought about this problem. It turns out that even in the black list we cannot enter the stolen updated token, since we don’t actually know it, it is not stored anywhere.

      As an option, to save some unique identifier of the token chain (token_id = 357) and when updating a new token with the same identifier (token_id = 357), the whole chain with one identifier will turn out. If the token is stolen and updated, then the real user, logging in using the old token, will receive an authentication form, after successfully sending the login and password, we can block the chain of tokens by a unique identifier (token_id = 357). And give the user a new token with a new chain ID (token_id = 358)

      • Confirmation of the validity of the token is its secret, which can be revoked at any time. - etki