As the most popular cross domain authentication scheme, JSON web token (JWT) is familiar to everyone. Many systems are using JWT instead of session authentication. What’s the difference between the two?
In short, JWT saves the authenticated data in the client and session in the server.
After using JWT instead of session authentication, the server does not need to maintain the session, and there is no need to store the session in a single point in a distributed environment. Because JWT is self explanatory, it’s OK to verify whether JWT is legal or not. It greatly improves the scalability of the system, and is especially suitable for the current environment where micro services are popular.
If the boss wants to kick people, what should he do?
The first idea is to store JWT in a central redis when JWT is promulgated. Every time you visit JWT, check whether there is this token in redis. If there is no such token, the authentication will fail. Just delete the user‘s associated JWT and you will be OK! You can go home and hold your daughter-in-law happily.
Wait a minute, this game completely goes against the original intention of JWT. The server has changed into a state again. Why take off your pants and fart? Just use session?
Seriously, the design of JWT is not suitable for such a scene.
What if we have to force users to log out?
It can be similar to oauth2 . After authentication, two tokens, access token and refresh token are issued.
- The access token is a JWT, which sets a shorter expiration time, such as 1 hour. The access token needs to be carried every time the back-end service is called. The frequency of round-trip network is very high, and the greater the possibility of exposure. Setting a shorter expiration time can also reduce the security risk.
- Refresh token to refresh a token. You can set a longer expiration time, such as one month, instead of JWT. Refresh token is mainly used to exchange new access token. Because it will only be delivered to the server when the access token is about to fail or has failed, a longer expiration time will not have too much security risk. When the token is issued, only the refresh token is saved in redis and the expiration time is set. When using the refresh token to exchange for a new access token, it is necessary to determine whether the refresh token exists in redis. If it does not exist, the refresh fails and the user needs to log in again.
If the client wants to maintain the login status for a long time, it needs to automatically use the refresh token to obtain a new access token when the access token fails. Or refresh the token in advance before the access token fails.
Now if we want to kick people, we just need to delete the refresh token related to the user from redis. After the current access token fails, there is no way to refresh the token. So as to achieve the purpose of forcing users to log out.
One drawback of this design is that it is not timely to force users to log out. There needs to be a time waiting for the access token to expire. If you want high timeliness, you can set the expiration time of the access token a little shorter, but the frequency of refreshing the token will increase. This needs to be weighed according to one’s own business.
Every time the service API is called, it is still the original JWT stateless authentication without accessing any central storage. Access to central storage is required only when the access token is refreshed. It’s a compromise.
Welcome to follow the author’s GitHub project and learn about micro services:
A multi store e-commerce system based on micro service architecture of spring boot
An e-commerce management background based on react