When interactive webpages were not popular in the early days, when we browsed the webpage, we only needed to get the webpage address to obtain webpage data at will. It was more friendly to users and servers, but they were also relatively simple. With the emergence of web pages similar to shopping carts and malls, people began to find that users need to perform identity authentication when accessing web pages to obtain user-specific data. At this time, our current interactive web pages gradually appeared. But our http protocol is connectionless and stateless, and multiple requests are unrelated and independent. Since the http protocol is stateless, how do we distinguish user identities?
Let us now imagine a scenario:
When we visit a webpage, we need to log in first, the server identifies the current user identity, and then uses the current identity to obtain the data on the server. And have you noticed that after we log in once, we don't need to log in again for a long time, so how is this achieved?
Some people will definitely say that we can save the account password in our local storage, so that every time we log in, let the browser complete the login by itself, won't it be possible to maintain the login status?
This seems to have solved the problem of automatic login, but it actually has very big drawbacks. First of all, it is very dangerous for us to store the user name and password in the local storage. Once our computer is attacked, the user name and password in our local storage The password is easy to be obtained by others. Secondly, although we can let the browser automatically log in for us, we still have not solved the stateless problem of the http protocol. Every request we initiate after that needs to let the browser find a way to help us add users It is very unreasonable to use the username and password to identify the user with the server and keep the login status.
So can we find a way to make every request automatically bring some data to the server for us, so that the server can identify us? From this, someone proposed the concept of cookie
cookie authentication:
When the client accesses the server for the first time, the server will generate a cookie, and store some data about user information in the cookie in the form of key-value pairs in the form of setCookie, and send it to our client, and the client will automatically Save data in our cookies. When the browser sends a request to the server next time, it will automatically carry the cookie to the server, and the server will return the data to the customer service after parsing the identity information in the cookie.
Features of cookies:
a. The cookie is stored on the client side
b. Cookies are not cross-domain. Each cookie is bound to a single domain name and cannot be used under other domain names.
c. The storage size of the cookie is about 4kb
d. There are two storage forms for cookies. One is stored in memory, called process cookie. First of all, we must know that when we open the browser, the process will be enabled, and the cookie will be stored in the process of opening the browser. When the browser When it is closed, the process ends and the cookie disappears. The second is: the client saves the form, called the hard disk cookie, which is saved in the hard disk, that is, a folder is generated under the browser installation directory, and there is an expiration time. Unless the user manually clears or the expiration time is reached, the data in the cookie will not It will disappear, otherwise it will be stored for a long time.
Advantages of using cookies:
1. Make up for the stateless shortcomings of the HTTP protocol
2. It is stored on the client, does not occupy server resources, and reduces server pressure
Disadvantages of cookies:
1. The cookie function of the browser can be actively disabled by the user. You can check whether the current browser cookie is enabled through the window.navigator.cookieEnabled property.
2. It can be directly operated by the user. The cookie is stored in the browser and stored in plain text, and can be directly viewed, modified or deleted by the user.
3. If the cookie contains key sensitive information, criminals may obtain the cookie through cross-site scripting (XSS), cross-site request forgery (CSRF) and other means, causing serious consequences.
Because the data in the cookie is stored in plain text, it is very insecure to transmit the cookie on the HTTP protocol, and it is also very insecure to store user information in the cookie. Therefore, in order to solve this problem, a session mechanism has emerged.
Session authentication:
When the user requests the server for the first time, the server will create a session based on our user information. The session contains a unique user identifier sessionID and the session end time. Regular string, and then the sessionID will be sent to the client in the form of a cookie as a carrier. After the browser receives our request response, it will automatically store the cookie. At this time, there is only one sessionID in the cookie. If our computer at this time Being attacked, the sessionID is obtained by others, and the sessionID that we transmit on the network is obtained by others. In fact, it does not make much sense, because he has no way to deduce the account password through our sessionID.
When we send a request to the server again, the cookie will be automatically carried to the server, and the server will obtain the sessionID from the cookie, and compare it with all the sessionIDs stored in the server memory. If the sessionID is found, it is considered that the session exists And not expired, return to the user data
Notice:
1. The session is not part of the cookie, it just uses the cookie as a carrier to transmit on the HTTP protocol
2. The session has a session period. The end time of the session period is set when the session is created, and the end time of the cookie is generally the session end time of the session.
We create a session to get the unique ID (sessionID) to identify the user. Does it solve the problem of unsafe storage of user information in clear text like cookies? Everything is perfect! But careful students discovered new problems:
When we create a session, will we store each new sessionID in the server's memory? When we next request the server, the server will hold the sessionID of this request and all the information in the server's memory. Compared with sessionID, does this mean that we have increased the pressure on the server invisibly? If we have a large number of users and high concurrent requests, is it easy to blow up the memory of the server? And if we request data from another server at this time, these sessionIDs are not stored in the memory of the other server, and the scalability is extremely poor.
So our leading technology leaders came up with a new solution. Can we just generate the user's unique ID on the server, but not store it, let this unique ID be stored on the client, and every time the client initiates Carry this logo to the server when requesting, and the server only performs identity verification? At this time token appears.
Token and Token Authentication
The resource credentials required to access the resource interface (API). The composition of a simple token: uid (the unique identity of the user), time (time stamp of the current time), sign (signature, the first few digits of the token are compressed into a hexadecimal string of a certain length by a hash algorithm).
Features: The server is stateless, has good scalability, supports mobile devices, is safe, and supports cross-program calls.
1. The client uses the username and password to request login
2. The server receives the request to verify the username and password
3. After the verification is successful, the server will issue a token and send the token to the client
4. After the client receives the token, it will store it, such as putting it in a cookie or localStorage
5. Every time the client requests resources from the server, it needs to bring the token issued by the server
6. 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.
7. Each request needs to carry a token, and the token needs to be placed in the HTTP Header
8. Token-based user authentication is a stateless server-side authentication method, and the server does not need to store token data. Use the calculation time of parsing the token in exchange for the storage space of the session, so as to reduce the pressure on the server and reduce the frequent query of the database
9. The token is completely managed by the application, so it can avoid the same-origin policy.
So our cookies, sessions, and tokens are actually generated on the server side to identify users. However, due to the insecurity of cookies, sessions appear, and sessions face server performance problems and poor scalability. Therefore, there is a token. In fact, many HTTP protocol requests now choose tokens to identify user identities, but tokens are not perfect. If, after we obtain the user's token, we directly put it into the request header, Sending a request to the server can also obtain user data. Besides, in the debugging process of the front-end and back-end separate development, everyone is willing to do this. The front-end will give the token obtained to the back-end to debug the interface, but the overall situation As mentioned above, our token mechanism does solve the function of user identity authentication. It is also friendly to both the server and the client, and will not cause performance problems.