Spring Cloud Combat and Thinking (iv) JWT token active failure

Demand:

in scenarios such as JWT leaks, password resets, and so on, it is necessary to proactively invalidate a JWT that has not expired but is already insecure .

  This article no longer repeats Jwt Span style= "Font-family:calibri" >google a bit. This is mainly for the above needs to talk about the solution. If the server is sent to the client, JWT JWT session mechanism, server-to- JWT JWT Once issued, it is out of the service-side control. Typically, the server can only be set by setting the JWT exp "declaration, so that the JWT

the so-called fish and bear cake can not be both. While we enjoy the convenience of JWT, we also need to design the mechanism of complex points to compensate for the weakness of the server to the JWT control ability. It is suggested on the web that the server keep a copy of the JWT that is issued to the distributed cache so that the JWT can be tracked and identified. This approach solves the problem, but each JWT is saved, and each check is done in a way that is almost no different from the distributed session . This is tantamount to giving up the benefits of a small server space and a fast validity check for JWT. In a scenario where there is no cross-domain resource access, the distributed session scenario has the advantage of preserving sensitive information at least in the session. Without worrying about being compromised on the client.

Here's what I'm using in my current project. JWT Control Solutions:

1. Each JWT must have an expiration time set and the time not set too long.

2. In the user Login table, assign a "token_group_id" field to each user. The field holds a random string.

3. Add the "groupId" statement to the payload of JWT. When a JWT is issued, the user's corresponding "token_group_id" string is written to the declaration.

{

"Exp": 1525256018000,

"GroupId": "jej4ivpr17z68q0ctr53gq25e588p653"

}

4. Save a "groupId" blacklist list on the distributed cache on the server side . If a user's JWT is compromised or a password reset is required to void a JWT that has been issued to a user , a new "token_group_id" is generated for that user . "Deposit the user login form." Add the original "token_group_id" to the blacklist.

5. Thetime to save "token_group_id" in the Blacklist is the expiration time of JWT. After expiration, "token_group_id" is automatically removed from the blacklist.

6. All servers that require JWT validation to access the distributed cache at startup time will download the blacklist to local memory. and subscribe to the distributed cache message push function, when the blacklist occurred additions and deletions, receive push message synchronization modify in-memory blacklist list.

7. When the server does the JWT check, in addition to check the expiration time, but also to query the in-memory blacklist list. If the JWT "groupId" is in the Blacklist, the JWT is determined to be invalid.

Discuss:

1. You also use the distributed cache for this scenario, and also to store the data in the cache. Is this not the same as the program nature of the distributed session or the Save all JWT ?

Although formally the same, the amount of data saved varies greatly. The other two scenarios need to preserve the complete collection of currently active users, and this scenario only stores insecure JWT. It is generally believed that the frequency of token leaks and password resets is relatively low. The percentage of JWT that needs to be revoked is small for the entire active user.

also JWT only stores an expiration period in the blacklist, which is then deleted, further controlling the blacklist growth. This allows the blacklist to be loaded into the server's memory, helping to complete The local validation of the JWT. You do not need to access the remote service every time you check.

2. Why superfluous add a "groupId", directly to the need to put the void of the JWT on the blacklist is not OK?

1) The JWT itself is relatively long, using a shorter "groupId" can speed up the blacklist query.

2) If the system does not limit the number of JWT that users can request at the same time . It is possible to encounter a situation in which a user maliciously requests a lot of tokens in a short period of time. These tokens are placed on the blacklist, causing the number of blacklists to expand rapidly. Using "groupId" can avoid this kind of uncontrolled situation.

3. You have a distributed cache for this scheme and a real-time synchronization of blacklists. The complexity of the implementation of the entire scheme seems to exceed the distributed session, will it not outweigh thedistributed session ?

1) in a slightly scaled distributed system, the distributed cache, the system bus are the necessary components. These existing components can be used to design multiple scenarios for data synchronization. So the scheme seems complicated, and it's not difficult to realize it.

2) Each system focuses on the performance indicators are different. the calculation and query of the JWT checksum for this scenario is done in local memory and does not need to rely on remote services. Can shorten the response time of the request. It is still appropriate for systems that emphasize low latency response.

Spring Cloud Combat and Thinking (iv) JWT token active failure