Phylogeny
1 Long, long ago, Web browsing is basically a document only, since it is the view, as a server, who need not be recorded in a certain period of time what documents are viewed, every request is a new HTTP protocol, it is to ask plus response, especially since I do not remember who had just made a HTTP request, each request is new for me. This time is very Hi skin
2, but with the rise of interactive Web applications, like online shopping site, website, etc. need to log in, and immediately faced a problem, that is to manage the session, who log must remember who go to their shopping put the car in the commodity, which means I must separate area for everyone, this is not a small challenge, because the HTTP request is stateless, so come up with ways is to give everyone to send a session identifier (session id), says white a is a random string, each person receives is different, every time you initiate to me when HTTP requests, this string to take along came together, so I can distinguish who is who
3, so it is very Hi skin, but the server is not leather Hey, everyone just needs to keep the session id, session id and the server you want to save everyone! If access to the server and more, and have made hundreds of thousands, even hundreds of thousands.
This is said to be a huge server overhead, severely limits the scalability of the server, for example, I use two machines form a cluster, small machine A through F logged into the system, and that session id will be stored on machine A, assuming that F is a small request is forwarded to the machine B how to do? Session id machine B may not small F ah.
Sometimes uses a little trick: session sticky, is to make a small request F has been sticking on the machine A, but this is not effective, and if the machine A hang, had to go to the machine B to go.
That had to make a copy of the session, the session id moved around between two machines quickly exhausted.
Later, a man named Memcached support of a trick: the session id stored centrally in one place, all the machines are used to access the data of this place, this way, they do not copy, but it increases the likelihood of a single point of failure, if that session is responsible for the machine hung up, everyone had to log in again and again, it is estimated Masi people.
Also try to put this machine also come up with a single point cluster, increase reliability, but no matter what, this little session for me is a heavy burden
4, so some people have been thinking about, why I want to save this nasty session it, just let each client to preserve nice?
But if you do not save the session id, how to verify a client's session id sent to me indeed is my generation do? If you do not verify, we do not know that they are a legitimate user is not logged on, those guys can forge malicious session id, do whatever they want.
Ah, yes, the key point is to verify!
For example, a small F has logged into the system, I sent him a token (token), which contains a proposed user id small F, the next time I visit small F again through Http request, when this token via Http header with not over it.
But this session id and there is no essential difference ah, anyone can be forged, so I have to do something about, so that others can not fake.
Then the data to make it a signature, for example, I algorithm HMAC-SHA256, a plus only I know the key, the data make a signature, the signature and the data together as a token, because the others do not know the key , the token can not be forged.
This token I do not save, when this small token to F me over when I use the same HMAC-SHA256 algorithm and the same key, the data re-calculated once the signature, and the signature token make a comparison, If so, I know that a small F has logged over, and can be taken directly to the user id small F, if not identical, the data portion certainly been tampered with, I'll tell the sender: Sorry, no certification.
Token data is stored in plain text (although I will do next with the Base64 encoded, but not encrypted), it can still be seen by others, so I can not in which to save sensitive information such as passwords.
Of course, if a person's token is stolen someone else, then I have no idea, I would think the thief is a legitimate user, and this is actually a person's session id was stolen someone else is the same.
As a result, I will not save the session id, I just generate token, then verify that token, I use my CPU time to obtain my session storage space!
The lifting of the session id of this burden can be said that nothing out of danger, my machine clusters can now easily do horizontal scaling, user traffic increases, plus the machine directly on the line. This stateless feeling is wonderful!
Token, Cookie is stored in the client ;
Session stored in the server on;
Cookie
A cookie is a very specific thing, refers to a data inside the browser can be permanently stored , is merely a data storage function of the browser implementation.
cookie generated by the server, sent to the browser , the browser cookie to kv form saved to a text file in a directory, the cookie will be sent to the server the next time you request the same site. Since the cookie exists on the client , the browser adds some restrictions to ensure the cookie will not be used maliciously, but will not take up too much disk space, so the number of cookie per domain is limited.
Session
Literally session is a session . This is similar to you and talk to a person, how do you know you talk to current and Joe Smith, not John Doe is it? There must be some other characteristics (appearance, etc.) that he is Joe Smith.
session is a similar reason, the current server you want to know who made the request to his yes.
In order to make this distinction, going to a different server for each client is assigned "identity", and then sent to the server each time the client requests the time, are put on the "identity", the server knows that the request comes from who had. As for the client how to save this "identity" can have a variety of ways, for browser clients, we are using the default cookie manner .
The server uses the user's session information temporarily stored in the server , user session after leaving the site will be destroyed. This user information is stored relatively cookie is more secure, but the session has a flaw: If the web server to do load balancing, then the next operation request to another server when the session will be lost.
Token
token means "token", is the user identity authentication, the simplest token consisting of: uid (user's unique identity), time (timestamp of the current time), sign (signed by former token several + salt is compressed to fixed length hash algorithm hexadecimal string, a malicious third party can be prevented splicing request token server). The same argument can also be put token, avoid multiple search library.
In the field of Web-based validation everywhere Token identity. In most use Web API Internet companies, tokens is the best way to handle multi-user authentication, stored in the client .
The following properties in the program will let you use the Token-based authentication
1. stateless, scalable;
2. support for mobile devices;
3. Cross-program calls;
4. Security;
Those using Token-based verification of the identity of the bigwigs, most of you have seen the API and Web applications use tokens. Such as Facebook, Twitter, Google+, GitHub and so on.
Token-based authentication principle of
Token-based authentication is stateless, we will not exist in the user information server or Session.
This concept solves many of the problems of information stored on the server
NoSession means you can program the machine to increase or decrease as needed, without having to worry about whether the user is logged in.
Token-based authentication is as follows:
1. The client sends a request via a user name and password.
2. Verify program.
3. The program returns a signed token to the client.
4. The storage client token, each time for each transmission request.
The authentication token and the server returns the data.
Each request requires token. token in the HTTP header to be transmitted to ensure the Http request stateless. We also by setting server properties Access-Control-Allow-Origin: *, so that the server can receive requests from all domains. Note that, when ACAO head marked (designating) *, not like with HTTP authentication, SSL certificates and client certificates of cookies end.
1. The user logs check, check after the success Token returned to the client.
2. client after receiving the data stored in the client.
3. The client to the server each time carrying Token to access the API.
4. The server uses the filter calibration filter. The requested data is returned check is successful, an error code is returned check fails.
When we get the token and authentication information in the program, we will be able to do many things through this Token.
We can even create a pass on third-party applications based on token privileges, these third-party programs can obtain our data (of course, only in a specific token we allow)
The difference between the cookie and session
1, cookie data is stored on the customer's browser, session data on the server.
2, cookie is not very safe, people can analyze stored locally COOKIE COOKIE cheat and
take into account security should use the session.
3, session will be stored on the server within a certain period of time. When accessing the increase would be more take up the performance of your server
take into account mitigating server performance, you should use COOKIE.
4, a single cookie stored data can not exceed 4K, many browsers are limited to a maximum of 20 sites saved cookie.
5, so personal recommendations:
the login information and other important information is stored as SESSION
additional information if necessary, it can be placed in COOKIE
The difference between the token and session
oauth token session and not contradictory, as the authentication token security better than the session, because each request signature also prevents eavesdropping and replay attacks, and the session would have to rely on the link layer to protect the security of communications. As mentioned above, if you need to implement stateful session, you can still increase the session to save some of the state on the server side
App usually dealing with a restful api with the server. Rest is stateless, that is not like the app browser as a cookie to store the session, hence the session token to mark themselves enough, session / state by the logic api server processing. If you are not stateless backend of rest api, then you may need to save the session in the app. Webkit can be embedded in the app, with a hidden browser to manage the cookie session.
HTTP Session is a storage mechanism, mechanism for persistent object stateless HTTP provided. The so-called Session of the certification simply storing information to the User Session, because of the unpredictability of the SID, for the time being considered safe. This is a means of authentication. The Token, when it refers to OAuth Token or similar mechanism, then, is to provide authentication and authorization, certification is for the user, is authorized for App. Its purpose is to allow a right of access to information App a user. Token here it is unique. Can not be transferred to another on the App, you can not go to the other users. Turn around and say Session. Session provides only one simple authentication, that this SID, that is considered to have all the rights of this User. Is the need for strict confidentiality of this data should only be stored in the station square, you should not be shared with other sites or third-party App. So simple, if your user data and may require a third-party share, or allow third parties to call API interface, with a Token. If you always just your own website, their own App, what it does not matter.
When the token is a token, such as your authorization (login) a program, he is a basis to determine whether you have licensed the software; cookie is written in a txt file on the client, which includes your login information and the like, so that you at login times a website, it will automatically call the cookie automatically log the user name; session and cookie, only in session is written in the file server, but also need to write cookie files on the client, but the file in your browser numbers .Session state is on the server side, the client only session id is stored; and Token status is stored in the client.
reference:
1. thorough understanding of the cookie, session, token
2. the session, the cookie, token difference and contact