Sorry ~ jwt does not support active expiration of user token.
to know the verification of a user's login identity, there are basically two types:
1 the client stores a random string and carries it when sending the request. After receiving it, the server takes this string to the storage for comparison to find the corresponding data.
2 stores all data to the client. This creates a security problem because the server cannot determine which data is valid and which data is bogus. So the concept of signature is introduced. The algorithm is used to ensure the credibility of the data.
early websites were basically a master site, and there was no distributed deployment. So most of them use the first way.
but as the number of visits increases and starts to be distributed, it involves the problem of session sharing. For example, the storage in 1 uses redis to achieve the effect of sharing data. But this will store a large amount of data on the server.
then, another kind comes out. Data is not stored on the server. One of them is jwt.
when jwt is generated, you can set the validity period. In theory, a user can generate countless jwt, and the validity of the jwt is independent.
if you want to invalidate a jwt that is still valid, you must store data on the server, which violates his design principle.
actually. His exit is that the client takes the initiative to throw away the jwt (assuming that it will not be picked up by others) < del > ~ < / del > ~ then this jwt does not exist ~ this completes the logout function ~
Logout depends on how your client stores jwt information. An important idea of using jwt is that the user state is maintained by the client in order to scale out the server.
there are many places to store jwt on the client. If cookie, local storage, session storage, or even IndexedDB or Web SQL, is a single-page application, the memory is also ok (but make sure that the user does not manually refresh the page, er). Of course, because jwt is sensitive information, it is best to put it in cookie and set it so that js cannot access it.
if the storage location is accessible to js, then so easy, sets jwt to none, which means logging out.
if it is a cookie, that denies js access, you need a specific header, in the response returned by the server to delete the cookie.
another: it is not comprehensive to say that jwt does not support active logout. I guess what the upstairs means is that depending on the state-holding mechanism, some logout operations do not require server-side participation at all.