Json web token (JWT), is a JSON-based open standard ((RFC 7519) implemented to transfer claims between web application environments. The token is designed to be compact and secure, especially suitable for single-site distributed sites. Point-on login (SSO) scenario.
The application of JWT is becoming more and more widespread, it has replaced the original login authentication method stored in the session, because this method consumes more memory when the number of users rises , And for distributed sites, although you can use shared session to achieve single sign-on, it consumes a lot of system.
1. Single-application session
login authentication in the traditional session+cookie mode, the login information is stored in the session, and the server returns a sessionId to the browser in the processed token. The single-application program is okay. Once the distributed application is used, the user The logged-in session is only stored in the application that handles the user's login. The next request may be deployed to another application by the load balancing mechanism, and the session will be lost. Moreover, in a single application, when the amount of session increases, the consumption of memory in response will also increase.
2. Session sharing The
cluster application can of course set up multi-application session sharing, but this has a certain consumption in system performance. For example, a tomcat cluster is built. Tomcat provides a way to share sessions. Redis is used to store the token of sessioniId persistently. Spring session is implemented using this principle, but redis is not 100% stable.
3. It
is inevitable for JWT to use the session method of login authentication to be replaced by JWT. JWT is also an appropriate verification method when developing back-end projects, and his token does not need to be placed in a cookie, and the front-end development will handle it casually, as long as subsequent requests It can be carried at the time.
The essence of JWT is that after the user logs in, a fixed-constrained encryption method is used to generate a time-effective json string token, which is generated by the back-end and returned to the front-end. The front-end must bring it every time a request is made. Holding this token. After that, the backend of the request will first intercept the request and parse the request. For all tokens that are not carried or timed out, the JWT will fail to parse during parsing, and the backend can perform logical processing of different situations according to the results. JWT does not occupy session resources, does not require persistent storage such as rredis, and does not waste other resources. It is precisely because of this that JWT can perfectly implement single sign-on verification in a distributed system.
4. JWT + redis to get the basic information of the logged-in user
In the actual development and application of JWT, the user information module basically stores a user UUID. When the user logs in, the user’s first request needs to use JWT to generate a later pass token, use UUID to generate a user ID, and place it in JWT. Once again, you can use UUID as the primary key before, and store the parsed user login object as value in redis, and set the time to be the same as the JWT valid time. After that, the user logs in with the token returned by the login. Through JWT to parse out the user UUID inside, you can directly retrieve some user information from redis, especially when you need some information about the currently logged-in user during business logic processing, you can use it directly without querying (user UUID acquisition The login user information class in redis can be encapsulated, which is very convenient for global use).