is that jwt should have source fields when encrypting. User modules should generate different jwtToken from different sources so that each sub-business logout will not have an impact

1) think about it, why use jwt to implement token, instead of other token types?

using jwt as token, then in the process of verifying token, there is no need to interact with the user module, which reduces the access pressure of the user module. However, the disadvantage of jwt is also obvious, so it is impossible to revoke token, so the token timeout time is generally set to be relatively short.

2) whether revoke token? is required

if you need to log out users through revoke token, then jwt is not a good choice. Generally, if you choose to use jwt as token, there is generally no need for revoke token. Because the properties of the jwt token are not stored in the background of the user module, but are packaged into the token itself, once the token is issued, it cannot be modified.

3) how to log out, partial logout

based on the system design of token, the logout process is generally revoke token,. Of course, if you only log out from some business modules, you can also mark token in the user module. For example, in the user module, modify the scope property of token.

4) Authentication or authorization?
Certification: tell me who you are? 401
Authorization: I know who you are, but do you have the right to do what you ask? 403

if the scope of modified token is used to realize the logout of some modules, the user authorization is actually cancelled, but the token itself is still valid and the authentication can still be completed through token,.

it's a clich . To put it simply, the scenario of using jwt should be stateless . The so-called stateless means that the server does not save any state information, so it is impossible to invalidate a token. This kind of scenario should be that the client deletes the token.
of course, the plan can not keep up with the change, so when this demand arises, we can only save the state of token on the server. Usually, the disabled information is saved, for example, when tokenA logs out of system A, maintaining a key, content in the cache is "tokenA has been logged out in system A". The expiration time is the same as that of token itself. Check the cache first.
but the complexity of the system increases a lot.