Token, Cookie and session difference--Learning notes

when you do interface testing, you often encounter the type of request parameter is token, but perhaps most testers have a smattering of token,cookie,session differences. To this end, I consulted a large number of data to do the following summary.
This article may be the most popular article about token, cookies and session, and try to read every word of the article, perhaps you will have a deeper understanding. Cookies

Cookies are a very specific thing, refers to the browser can be stored in a permanent data, is only a browser implementation of a data storage function.

Cookies are generated by the server, sent to the browser, and the browser saves the cookie in KV to a text file in a directory and sends the cookie to the server the next time the same site is requested. Because cookies exist on the client side, the browser adds some restrictions to ensure that cookies are not used maliciously and do 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 John rather than dick. There must be some kind of trait (looks, etc) that indicates that he is John.

Session is similar to the truth, the server to know the current request to their own who. 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 is from. As for the client how to save this "identity", there can be many ways, for the browser client, everyone defaults to the way cookies.

The server uses session to temporarily save the user's information on the server, the user leaves the site after the session will be destroyed. This type of user information storage is more secure than cookies, but session has a flaw: if the Web server does load balancing, the next operation will be lost when it requests another server. Token

Token means "token", is the user authentication method, the simplest token composition: UID (user unique identity), time (timestamp of the current time), sign (signature, by the token of the first few + salt in the hash algorithm compressed into a certain length of hexadecimal strings, Can prevent malicious third party stitching token request server). You can also put the invariant parameters into token to avoid multiple Chaku of traditional authentication

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

The solution is, when the user requests to log in, if there is no problem, we generate a record in the server, this record can explain the user who is logged in, and then the ID number of this record sent to the client, the client received the ID number stored in the Cookie, The next time the user sends a request to the server, you can take this cookie so that the server verifies the information in the cookie to see if it can find the corresponding record in the server, and if so, 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 in the server to log on the user generated sessions, which may be stored in memory, disk, or database. We may need to periodically clean up expired sessions on the service side. Token based Authentication

Using the Token authentication method, you do not need to store the user's logon record on the server side. The approximate process is this: The client uses user name and password request login server to receive the request, to verify the user name and password after the successful authentication, the server will issue a Token, and then send this Token to the client client after receiving Token can store it, such as in a Cookie or In the local Storage, each time the client requests resources from the server, it needs to receive a request with the Token server that is issued by the server, and then verify the Token in the client request and return 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 authenticates the username and password, and if it succeeds, in some way such as a randomly generated 32-bit string as a token, stored in the server and returned token to app, later app requests, All need to verify the place to take the token, and then server-side validation token, successfully return the desired results, failure to return the error message, let him log in again. The server token set an expiration date, each time the app requests to verify the token and validity period.

So here's my question: 1. The token on the server is stored in the database, and each query can be time-consuming. If you do not store the database, where should it be stored? 2. The client obtains the token certainly to encrypt the storage, sends the token to decrypt again. Is it stored in a database or a configuration file?

Token is a volatile data, lost nothing more than let the user login again, Sina micro-blog to let me log on again, anyway this matter I do not care.
So if you think the normal database tables won't hold up, can be put into the Mssql/mysql memory table (but it is said that MySQL's memory list performance is limited), can be put into the memcache (to tell the truth, this is a very common strategy), can be put into the Redis (I did this implementation), 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 the tickets, tickets lost to buy again, Token lost a re-operation certification one can be, so the cost of token lost is tolerable-the premise is that you do not lose too often, if you let the user Gesanchaiwu certification once that loss of user experience.

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

Client side This unless you have a very secure solution, such as the privacy data store provided by the operating system, the token is sure to leak. For example, I get your mobile phone, token your copy out, before the expiration of all can be in your capacity to log in elsewhere.
A simple way to solve this problem
1, in the storage when the token for symmetric encryption storage, when the unlock.
2, the request URL, time stamp, token three to add salt signature, service-side validation.
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, in fact, it is not difficult to say, so after all, is to prevent a gentleman from the practice of the villain. To say that encrypted storage one if you are being clawed the client will not be sprayed with clear text storage ...
Method 1 It gets the storage of the ciphertext solution, Method 2 It does not know your signature algorithm and salt, both can be combined to eat.
But if token is handcuffed, he can also be implanted into his mobile phone, then his mobile phone can also be used as your identity, which you are blind.
So you can provide a mechanism that allows users to proactively expire a past token, and can stop at the time of theft.

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