As mentioned earlier, because cookie are stored in the client, there are security risks, so session was born. Sessions are stored on the server, which is more secure. However, every session needs to open a space for users to verify their identities, and every time a browser request comes to the server, it needs to be verified, which consumes a lot of space and performance of the server.
Thus, another authentication tool was born, which is token.
In essence, it is also a user authentication tool. However, unlike the plain text form of cookie and session, token is encrypted by a series of encryption methods, and finally appears as a string of meaningless characters. But it contains a lot of information, which may include the terminal address, user ID, timestamp and signature of the user. The so-called signature means that the sender of the information signs this message to let the receiver know who the request token belongs to. It can be understood as double authentication of signature, certificate and handwriting on your ID card.
In order to avoid the above CSRF attack, the browser puts forward restrictions on the access to web resources, and the URL request must come from the same protocol, domain name and port as the page in order to give access rights. In this way, the same site is considered to have the same "source" and independent "domain" Even if "localhost" and "ip" both point to this machine, it will be considered as non-homologous. Browsers will not execute scripts from other domains under one domain. Therefore, this also produces an important topic in the front-end field: cross-domain.
The generation of session comes from a session object generated by the server after the user logs in and is saved on the server side. This session applies only to this domain. But the reality is that the request of a website will cross domains in most cases, and the port of each server is different, even the domain name is different. Whenever it crosses the domain, it will form a new session and produce a new session, which will have a great impact on the user experience, so there will be many schemes to save, * * * share or centrally store the session.
But the above two restrictions are not a problem here in token.
Similar to cookies.
First, the user enters the account password and initiates a login request. The server verifies the validity of the account password and returns the token to the client if it is successful.
After receiving the response, the client obtains the token and saves it through the localStorage method (such as local storage).
When the browser requests again, it is necessary to add a token in the request header, so that the server can recognize whether the identity of the request is legal after receiving the request, and return the response data if it is legal.
In practical application, it is very convenient to use the request interceptor of axios:
In this way, we don't have to manually add token every time we request it, and axios will automatically help us add it, which is very convenient.
In fact, the front-end programmer is not deeply involved in token, just need to carry token in the request that needs authorization. Token generation and encryption are handled by the backend. Therefore, the encryption principle of token is not introduced in detail here, which is difficult to explain clearly with the author's ability.
The use of token is not as simple as described above, which involves some operations such as expiration processing and refreshing. These will be discussed in detail later.