In the early stage of the development of the Internet, the web is basically just content browsing. The server does not need to remember the status of each browsing request. In other words, the server does not need any status information. Each client request is a new request, which is also an obvious manifestation of HTTP statelessness. With the advent of the Internet tide, especially the rise of a large number of systems closely related to users such as online shopping, the system needs to identify users in order to carry out various business operations. This demand has a strong impact on the stateless feature of HTTP. Therefore, the final solution is to carry an identification when the client requests, This identification is different for each user, so that the server can distinguish different client users according to this identification, which gives birth to the concept of user authentication.
Because HTTP protocol is stateless, authentication based on HTTP protocol needs to rely on some identification uploaded by the client
The so-called identity authentication is the process of judging whether a user is a legal user.
The above is the generic definition of user authentication and authentication related authorization in encyclopedia. By the way, authentication and authorization are two different concepts and two different stages. The vast majority of systems with authentication and authorization are authenticated first in the user operation process, and then authorized according to the authentication results, Some beginners are easy to confuse the two concepts. Take a simple example: in an OA system, after the user logs in successfully, a menu tree with different operations will appear on the left according to the different roles or permissions of the current user. The process of user login is the process of authentication, and the menu tree on the left is a specific form of authorization for the current user (of course, some systems may not do this), But it does not mean that there is no authorized process).
Authentication is an operation process used to prove a user’s identity, and authorization is an operation process used to grant permissions to the current user.
Through the last article, I believe you have understood the relationship between session and cookie. If you haven’t read it yet, I recommend you take a look.
Session: in computers, especially in network applications, it is called “session control”. The session object stores the properties and configuration information required for a specific user session. In this way, when the user jumps between the web pages of the application, the variables stored in the session object will not be lost, but will exist throughout the user session. When a user requests a web page from an application, if the user does not have a session, the web server will automatically create a session object. When a session expires or is abandoned, the server terminates the session.
The main feature of session based authentication is that the server stores user information, and the client identifies the session by carrying a session ID cookie. Many initial projects like to adopt session authentication, which is very beneficial to the rapid development of online projects. Each client only needs to save one cookie, but the server needs to save thousands of user session information, which undoubtedly puts great pressure on the server. Especially after load balancing, the session hit problem is even more terrible. For example, if user a logs in to the system successfully, server a issues the sessionid, and the session information is stored on server A. if the next request is made to server B, there is no session information on server B, so there will be a miss, which is also a problem faced in the implementation of session authentication solution. There are solutions to problems. One of them is session replication. Each server on the server side stores a copy of each session, so that no matter which server the request reaches, it can successfully get the session information. However, this undoubtedly increases the storage pressure of the service, and the replication delay between servers, the update and synchronization of session information Expiration synchronization and other operations are troublesome. Therefore, this scheme is not recommended to a certain extent.
At present, the industry’s solutions for session storage generally tend to centralized storage. For example, redis and memcached use a third party to store session information in the same place, and all servers access the data in this place. This avoids problems such as session replication and synchronization. However, the introduction of a third party means that the possibility of a third party hanging up is increased. Therefore, the third-party cluster scheme is basically adopted to minimize this possibility and maximize the high availability. In addition, since most session mechanisms are based on cookies, they are friendly to browsers to a certain extent, but they are not very friendly to many mobile applications.
Since the session authentication information is stored on the server, the amount of data reaches a certain level, which has a certain pressure on the server. Even if the third-party storage (such as redis) can alleviate this problem, the IO operation of the server and the third-party storage sometimes takes a lot of time. In this case, some systems give up the session authentication method and directly use the most direct cookie authentication method.
Unlike session authentication, the user’s authentication information is completely stored in a cookie, in other words, the user’s authentication information is stored on the client (which is why it is not recommended to store sensitive information in cookie authentication). The advantage of cookie authentication is that the server does not have the pressure of session storage. It only needs to parse the contents of the cookie every time it identifies the user (it also takes time to parse the cookie). Compared with the third-party storage of session, it reduces a network IO operation and improves the response speed of the request to a certain extent, Moreover, because the server is in a stateless form, it can be easily expanded horizontally.
Cookie based authentication also has many disadvantages:
- Cookies are stored on the client, so it increases the probability that they can be forged to a certain extent, and the security is slightly weak.
- Cookies are limited in length, so they should not store too long information.
- The user’s client may disable cookies. At this time, you can rely on URL value transmission to solve this problem.
- It is difficult for the server to operate the invalidation of cookie authentication information, which is not as convenient as session authentication.
In fact, the old systems of our company use the cookie authentication method, but the encryption algorithm of cookie information is very good, and coupled with the HTTPS strategy of the whole site, the security is still OK to a certain extent (if I reconstruct the authentication system, I won’t choose cookie authentication).
Write at the end
Whether session based or cookie based authentication, the client needs to upload the identity, the server needs to issue the identity, and encrypt the identity. Although it is encrypted, once an illegal person obtains this identity, he can still carry out a series of illegal operations. Therefore, it is better to add the attributes of source IP and expiration time to this identity, and configure HTTPS to more effectively protect the whole authentication process and data. Maybe there is a better way of authentication, please look forward to it!!
More wonderful articles