1.session authentication method
- We know that the http protocol itself is a stateless protocol, which means that if the user provides a user name and password to our application for user authentication, then the next request. The user needs to perform user authentication again, because according to the Http protocol, we do not know which user sent the request, so in order for our application to identify which user sent the request, we can only store a copy on the server The user's login information (session), and then save a sessionid in the client's cookie, and the client will carry this cookie to the server for each subsequent request to find the corresponding session. This way our server knows which user the request came from.
2. Authentication process
3. Exposing problems
* After each user is authenticated by our application, our application must make a record on the server side to facilitate the identification of the user's next request. Generally speaking, the session is stored in memory, and with the increase of authenticated users, The overhead of the server will increase significantly.
* After user authentication, the server makes authentication records. If the authentication records are stored in memory, it means that the user's next request must be requested on this server, so that the authorized resources can be obtained. For distributed applications, the load balancing capability is correspondingly limited. (In order to solve this problem: we need to share between clusters. Use cache: redis and other caches for sharing)
*Because the user identification is based on the cookie, if the cookie is intercepted, the user is vulnerable to the attack of cross-site request forgery (after intercepting the cookie, use the sessionid to access)
1.jwt authentication process
* First, the front-end sends its user name and password to the back-end interface through the web form. This process is generally an Http Post request. The recommended way is to use SSL encrypted transmission (https protocol) to avoid sniffing of sensitive information.
* After the backend checks the user name and password successfully, it takes the user's id and other non-sensitive information as the JWT Payload (load), performs Base64 encoding splicing on it and the header, and then signs to form a JWT.
* The backend returns the JWT string to the frontend as the return result of successful login. The front end can save the returned result in localStorage or sessionStorage. When logging out, the front end deletes the saved JWT.
* The front end puts the JWT into the Authorization bit in the HTTP Header every time it requests. (Solve XSS and XSRF issues)
* Every time the front-end requests, it will carry JWT, and then the back-end interceptor intercepts the request to verify the validity of JWT (for example: check whether the signature is correct; check whether the token is expired, etc.)
2. Advantages of JWT
* Introduction (Compact): It can be sent via URL, POST or HTTP Header, because the data volume is small, so the transmission speed is also fast.
* Self-contained: The payload contains some user's non-secret information, such as id, etc., avoiding multiple queries to the database.
There is no need to save session information on the server side, especially when using distributed microservices.
