Why store it after the server generates Token ?

from the official documents of JWT, we know that, JSON WEB TOKEN consists of three parts:

• Header
• Payload
• Signature

here we only talk about the saved content in Payload , quoted from the JWT official:

The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional metadata. There are three types of claims: registered, public, and private claims.

from this we can see that the Payload part of token has the ability to store user ID, roles. That is, it fully embodies the self-explanatory characteristics of TOKEN .

in that case, why should we persist Token in a cached database like Redis ? Can Token be persisted by the client?

I have consulted my friends, and most of my answers are: access is fast and it is easy to expire .

so let"s assume that if we don"t store Token on the backend, the information in Payload is

{
  "id": "1234567890",
  "name": "John Doe",
  "admin": true
  "expire": 1527833009000
}

then when the client carries this token to visit the server, the server performs two steps of processing:

1. decrypt and verify the Signature part to ensure that token has not been tampered with.
2. parses Payload data, and determines whether it expires based on the attribute expire .

so can we avoid retrieving token in redis every time the client visits?

now when you visit the server with token on the client side, do you need to go to redis for verification every time?

also in the architecture design of micro-services, the external service may be provided by an API gateway or multiple API gateways, so our Redis must be installed on a separate physical machine or VM, so every time we check the validity of token , do we have to connect to the remote Redis server to retrieve data and then verify it?

Thank you all!