Problems with setting expiration time using jwt

1. When the user logs in successfully, a token, is issued to set the expiration time, which is assumed to be 2 hours.

2. When the user is more than 30 minutes from the expiration time, the user carries the original token access interface, and the original token, is still valid if the new token is not issued.

3. When the user is less than 30 minutes from the expiration time, but does not expire, and the user carries the original token access interface, the original token of the new token, becomes invalid.

4. When the user"s token has expired, issue a new token directly.

this gives users half an hour of no-operation judgment, which is somewhat similar to the previous session. What I want to ask is, is there any drawback to this?

Jwt
Mar.13,2021

using jwt means that the authorization cannot be revoked, but it can be revoked by expiring in the token; in
point 3, you cannot invalidate the original token because you do not know whether the token has issued a new token, or not if it is stored in a database. (this also violates the jwt design?)
Point 4: expired token, cannot issue a new token, directly, and the new token, must be issued with the correct authorization. (this may be your clerical error to express the intention of re-authorization.)

session server, jwt token client, jwt cannot actively revoke authorization.
to say the drawback, is the third point of multi-authorization token problem? It doesn't seem to be a big problem.


each user has his own secret key. If you log out, modify the key once. Is that all right?

Menu