Token, the difference between a cookie and a session--study notes

In the interface test, often encountered the request parameter is the token of the type, but perhaps most testers of the difference between the token,cookie,session or smattering. To this end I consulted a large number of information to do the following summary.
This article may be the most popular article about tokens, cookies and the difference between sessions, and take a good look at every word of the article, perhaps you will have a deeper understanding. Cookies

A cookie is a very specific thing, refers to the browser can be permanently stored in a data, is only a browser implementation of a data storage function.

The cookie is generated by the server, sent to the browser, and the browser saves the cookie in KV form in a text file in a directory, and the next time the same website is requested, the cookie is sent to the server. Because the cookie is present on the client, the browser has added some restrictions to ensure that the cookie is not used maliciously and does not occupy too much disk space, so the number of cookies per domain is limited. Session

The session is literally a conversation. This is similar to how you talk to a person, how do you know that the current conversation with you is Zhang San rather than John Doe. The other person must have a certain character (looks, etc) to show that he is Zhang San.

The session is similar to the truth, the server should know who is currently sending the request to itself. To make this distinction, the server assigns a different "identity" to each client, and then each time the client sends a request to the server, it takes the "identity" and the server knows who the request came from. As for the client how to save this "identity", there can be many ways, for the browser client, everyone is the default way of using cookies.

The

Server uses the session to temporarily save the user's information on the server, and the session will be destroyed after the user leaves the site. This user information is stored in a more secure way than a cookie, but the session has a flaw: if the Web server is load balanced, the session is lost when the next operation requests to another server. Token The Login Token token Introduction  token value describes the token value:  the login token. Use the token value to determine the user's logon status. Similar to the long string after MD5 encryption. After the user has successfully logged on, the backend (server side) generates a unique value based on the user information. This value is the token value. Basic use: The token value is stored on the server side (database), which is used to retrieve the corresponding user information and determine the user's login status. After the user logs in successfully, the server returns the generated token value to the client, and the token value is also saved at the client. (It can be stored in a cookie, or you can manually determine where to save it (e.g. preferences)). The token value (passed to the server as a parameter) will be automatically shipped by default when the client sends a new network request. The server gets the token value passed by the client and compares it to the token value stored in the database to determine the user identity and login status. Determine the login status: If the client does not have this token value, it means that the user is not logged in successfully and prompts them to log in. If the client has a token value, the login is generally considered successful. No user login required (enter account and password information). Token value extension: Token value has expiry time: General app, token worth the expiration time is more than 1 years. Special app: Bank app/Payment class App:token value expiration time is about 15 minutes. Once the user information changes (password change), the new token value will be generated on the server, the original token value will be invalidated. You need to enter your account number and password again to get the new token value generated. Uniqueness judgment: Each time you log in, a new token value will be generated. The original token The value is invalidated. Use time to determine the difference between logins.

Token means "tokens", which is the authentication method of the user identity, the simplest token composition: UID (user's unique identity), time (timestamp of the current time), sign (signature, the hash algorithm is compressed into a long hexadecimal string by the first several + salts of token, Can prevent malicious third party stitching token request server). You can also put immutable parameters into token, avoiding multiple Chaku of traditional authentication

HTTP is a stateless protocol, meaning that it does not know who is accessing the app. Here we regard the user as the client, the client uses the username and password to pass the authentication, but the next time the client sends the request again, it has to be verified again.

The solution is that when the user requests to log in, if there is no problem, we generate a record on the server, this record can explain the user who logged in, and then send this record ID number to the client, the client receives the ID number stored in the Cookie, The next time the user sends a request to the server, it can take this cookie so that the server verifies the information in the cookie to see if it can find the corresponding record on the server, and if so, indicates that the user has passed the authentication and returns the user's requested data to the client.

This is the session, we need to store the server as a login user generated session, these sessions may be stored in memory, disk, or database. We may need to periodically clean out the expired Session on the server side. Token-based authentication

Using the Token-based authentication method, there is no need to store user login records on the server side. The approximate process is this: the client uses the user name and password request log on the server to receive the request, to verify the user name and password verification success, the server will issue a token, and then send this token to the client client received token can be stored, such as in a Cookie or In the Local Storage, each time a client requests a resource from the server, it needs to receive a request with the token server issued by the server, then verifies the token that is in the client request and returns the requested data to the client if the validation succeeds.

When the app logs in, it sends an encrypted username and password to the server, the server verifies the username and password, if successful, in some way randomly generates a 32-bit string as token, stores it to the server, and returns token to the app, when the app requests it, Any place that needs to be verified takes the token, and the server verifies the token, returns the desired result successfully, fails to return an error message, and lets him log back in. The token on the server is set to a validity period, each time the app requests to verify token and validity.

So here's my question: 1. Tokens on the server are stored in the database, and each query is time-consuming. Where do you want to store it if you don't store it in a database? 2. The token received by the client must be encrypted and then decrypted when the token is sent. stored in a database or a configuration file.

Token is a volatile data, lost nothing but to let the user log in again, Sina Weibo let me re-login, anyway this matter I do not care.
So if you feel that the normal database table can't hold up, you can put it in Mssql/mysql's memory table (but it's said that MySQL's memory tables are limited in performance) and can be put into memcache (this is a very common strategy) that can be put into redis (I've done this), You can even put it in the Openresty variable dictionary (as long as you have confidence not to burst the memory).

Token is a rule, but it is more gentle than tickets, tickets lost re-pay to buy, token lost the re-operation of the certification of a can be, so the cost of token loss is tolerable-if you do not lose too often, if you let users go out certification once that the loss of user experience.

Based on this starting point, if you think that using a database to keep token query time too long, will become your system bottleneck or hidden trouble, can be placed in memory.
For example, memcached, REDIS,KV Way is suitable for your token query requirements.
This will not take up too much memory, such as your token is a 32-bit string, if your user volume in millions or tens, then how much memory.
If the amount of data is really large enough for a single machine memory, or think that a full risk of downtime, as long as this token generation is sufficiently uniform, high and low bits cut to different machines on the line, memory is definitely not a problem.

Client side of this, unless you have a very secure approach, such as a private data store provided by the operating system, there is a problem with the token being compromised. For example, I get your phone, copy your token out, and you can log in as your identity before it expires.
An easy way to solve this problem
1, when the storage of tokens for symmetric encryption storage, time to untie.
2, the request URL, time stamp, token three of the combination of salt signature, service-side check validity.
The starting point for both approaches is that it's easier to steal your stored data, and it's harder to disassemble your program hack your encryption and decryption and signature algorithms. However, it is not difficult to say that it is difficult, so after all, it is the practice of anti-gentleman. Say encrypted storage one if you're being clawed at the client, you won't be sprayed with the plaintext store ...
Method 1 It gets the stored ciphertext solution is not open, Method 2 It does not know your signature algorithm and salt, the two can be combined edible.
But if the token is copied, he can also be implanted into his mobile phone, then his mobile phone can also be used as your identity, which you are blind.
This provides a mechanism that allows the user to proactively expire a past token, which can be used to stop the loss at the time of theft.

Token transmission at the network level is very dangerous, so it is recommended that you use HTTPS and put tokens in the post body.