In this article, a brief understanding of cookie/session mechanism , the principle of cookie and session is briefly explained. This article will briefly explain another technical term that is as important as cookie/session: token.
What is a token
Token means “token”, which is a string of strings generated by the server as an identifier for the client to make a request.
When the user logs in for the first time, the server generates a token and returns this token to the client. In the future, the client only needs to bring this token to request data without having to bring the user name and password again.
The composition of a simple token; uid (user’s unique identity), 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.) Prevent token leakage).
Identity authentication overview
Since HTTP is a stateless protocol, it does not know who accessed our application. The user is regarded as a client here, and the client has passed the authentication using the user name and password, but the next time the client sends a request, it has to be verified again.
The general solution is, when the user requests to log in, if there is no problem, generate a record on the server side, in this record, you can indicate who the logged in user is, and then send the id of this record to the client, the client After receiving it, store this id in the cookie. Next time the user sends a request to the server again, he can bring this cookie, so that the server will verify the information in the cookie and see if the corresponding can be found on the server. If it is possible, it means that the user has passed the authentication, and the data requested by the user is returned to the client.
The process described above is to use the session, and the id value is the sessionid. We need to store the sessions generated for users on the server. These sessions will be stored in memory, disk, or database.
Identity authentication based on token mechanism
The authentication method using the token mechanism does not need to store the user’s login record on the server side. Approximate process:
- The client uses the username and password to request a login.
- The server receives the request and verifies the username and password.
- After the verification is successful, the server will generate a token, and then send this token to the client.
- After the client receives the token, it stores it, which can be placed in a cookie or Local Storage.
- The client needs to bring the token sent by the server every time it sends a request to the server.
- The server receives the request, and then verifies the token in the client request. If the verification succeeds, it returns the requested data to the client.
The token mechanism can be used for login authentication in the following ways:
a. Use the device mac address as the token
Client: The client obtains the mac address of the device when logging in, and passes it to the server as a parameter
Server: After receiving the parameter, the server uses a variable to receive it, save it as a token in the database, and set the token in the session. Each request of the client must be intercepted uniformly, and the token passed by the client is compared with the token in the server-side session. If the same is the same, the login is successful, and the difference is rejected.
In this way, the client and the server unify the unique identification and ensure that each device has a unique identification. The disadvantage is that the server needs to save the mac address; the advantage is that the client does not need to log in again, as long as it can be used after logging in once, the server will handle the timeout problem.
b. Use sessionid as token
Client: The client carries the user name and password to log in
Server: After receiving the user name and password, verify it, and return the locally obtained sessionid as a token to the client if it is correct. The client only needs to bring the requested data in the future.
The advantage of this method is that it is convenient and does not need to store data. The disadvantage is that when the session expires, the client must log in again to request data.
Of course, for some applications with high confidentiality, a combination of two methods can be adopted to authenticate the device mac address and user name and password as tokens at the same time.
APP uses token mechanism for identity authentication
When the user logs in to the APP, the APP will send the encrypted user name and password to the server, and the server will verify the user name and password. If the verification is successful, it will generate the corresponding number of characters and store it in the server as a token, and return the token to APP side.
When the APP requests again in the future, you must bring the token wherever you need to verify, and then the server verifies the token, and returns the required result successfully, and returns an error message if it fails, allowing the user to log in again. Among them, the server will set a validity period for the token, and the token and validity period will be verified every time the APP requests.
Token storage
The token can be stored in the database, but it may take too long to query the token and cause the token to be lost.
In order to avoid too long query time, you can put the token in the memory. In this way, the query speed is definitely not a problem, and there is no need to worry too much about occupying memory. Even if the token is a 32-bit string, the number of users of the application is in the millions or tens of millions, which does not occupy much memory.
Encryption of token
Token is easy to leak. If it is not encrypted, it is easy to be copied maliciously and used to log in. Encryption methods generally include:
- The token is symmetrically encrypted and stored when it is stored, and then decrypted when it is used.
- The signature sign mentioned at the beginning of the article: Combine the request URL, timestamp, and token, and encrypt it through an algorithm.
It is best to use a combination of the two methods.
Another point is that it is very dangerous to use the plaintext transmission of the token at the network level, so the HTTPS protocol must be used.
Summarize
The above is a brief summary of the token in the user identity authentication process. I hope that product managers with no technical background will stop being asked about these technical terms when communicating with their development brothers.
