Common identity authentication methods such as passwords and certificates are only used to log in to the system. After the login is completed, it is impossible to verify the password and account for each request. Therefore, after the login is successful, there needs to be a mechanism that is transparent to the user for verification. It is the session (at the same time, the session also has a role to save the user state)
cookie-session mechanism
principle
- First visit
- If you have never logged in to a website before, cookies will not be carried in the http header. The browser generates a session-id for the logged-in user and returns it to the browser, and the browser saves the session-id on the client.
- Subsequent visit
- When accessing, it will carry the session-id assigned by the server in its own cookie. After receiving it, the server will index the user information in its own cache according to this session-id, and return the saved user data to the client.
- Long time later visit
- The cookie is invalid. Re-visiting it after a long time will regenerate the session-id to invalidate the original session-id.
The most common practice of sessionID is to save it in a cookie. In addition, it can also be saved in a URL, but this is not very safe. At present, many mobile browsers do not support cookies. In this case, it can only be saved in the URL. .
Disadvantages
-
Server pressure increases : usually sessions are stored in memory. After each user is authenticated, session data is stored in the server's memory. When the number of users increases, the pressure on the server increases.
One solution is to encrypt the session in the cookie. When the browser accesses the webpage, bring this cookie, and the server side only needs to decrypt it to get the user's session.
-
CSRF cross-site request forgery attack : session is based on cookie for user identification, if cookie is intercepted, users will be vulnerable to cross-site request forgery attack, cookie hijacking https://blog.csdn.net/qq_39328436/article/ details/114262076
-
Scalability is not strong : If multiple servers are built in the future, although each server executes the same business logic, the session data is stored in memory (not shared), and the first time the user accesses server 1 , When the user requests again, another server 2 may be accessed. If the server 2 cannot obtain the session information, it is determined that the user has not logged in.
token mechanism
In the cookie-session mechanism, the biggest drawback is that the server has to store the session, and the token is mainly used to alleviate this contradiction.
principle
When the client visits for the first time, the server issues a token to the client, and the next time the client visits again, it carries this token to complete an identity authentication.
The token verification process:
- The client uses the user name and password to request login
- The server receives the request to verify the user name and password
- After the verification is successful, the server will issue a Token, and then send the Token to the client
- After the client receives the Token, it can store it, such as in Cookie or Local Storage
- The client needs to bring the Token issued by the server every time it requests resources from the server
- The server receives the request, and then verifies the Token contained in the client request. If the verification is successful, it returns the requested data to the client
session VS token
1. The session is stored on the server side, which leads to increased server pressure, which is not conducive to server expansion. The token is stored on the client, and the server exchanges computing time for storage space.
2. The token is more secure. Sending the token in the request instead of sending the cookie can prevent CSRF (Cross Site Request Forgery), because the token will be spliced in the URL and is difficult to forge.