Shulou(Shulou.com)06/01 Report--

Editor to share with you what is the difference between cookie, session and token, I believe that most people do not understand, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

History of development

1, a long time ago, Web is basically just a document browsing, since browsing, as a server, do not need to record who browsed what documents in a certain period of time, each request is a new HTTP protocol, that is, the request plus response, especially I do not have to remember who just sent the HTTP request, each request is new to me. I've been very naughty these days.

2. But with the rise of interactive Web applications, such as online shopping sites, websites that need to log in, etc., we are immediately faced with a problem, that is, to manage sessions, we have to remember who logs into the system and who puts goods in their shopping cart, which means that I have to distinguish everyone, which is a big challenge, because HTTP requests are stateless. So the way to come up with is to send you a session ID (session id). To put it bluntly, it's a random string, and everyone receives it differently. Every time you send a HTTP request to me, bring this string along with it, so I can tell who is who.

3. In this way, everyone is very naughty, but the server is not naughty, everyone only needs to save their own session id, and the server needs to save everyone's session id! If you visit more servers, it will have to be tens of thousands or even hundreds of thousands.

This is a huge overhead for the server, which seriously limits the server's expansion ability. For example, if I use two machines to form a cluster, and Xiao F logs in to the system through machine A, then the session id will be saved on machine A. what if the next request of Xiao F is forwarded to machine B? Machine B doesn't have a small F session id.

Sometimes a little trick is used: session sticky, which keeps Xiao F's request attached to machine A, but it doesn't work. If machine A dies, it has to be transferred to machine B.

Then I have to copy the session and move the session id between the two machines. I'm exhausted.

Later, there was a trick called Memcached: store the session id in one place, and all the machines come to access the data in this place, so that there is no need to copy, but it increases the possibility of a single point of failure. If the machine in charge of session dies, everyone will have to log in again, probably scolded to death.

I also try to get this single-point machine out of the cluster to increase reliability, but in any case, this small session is a heavy burden for me.

4. So someone has been thinking, why should I save this abominable session, and it would be nice to let each client save it?

But if I don't save these session id, how can I verify that the session id sent to me by the client is actually generated by me? If we don't verify it, we don't know if they are legitimate login users, and those with bad intentions can fake session id and do whatever they want.

Well, by the way, the key point is verification!

For example, if Xiao F has logged in to the system, I will send him a token containing Xiao F's user id. The next time Xiao F accesses me through Http request, just bring the token over Http header.

But there is no essential difference between this and session id, anyone can forge it, so I have to think of something so that others can't forge it.

Let's make a signature to the data. For example, I use the HMAC-SHA256 algorithm, add a key that only I know, sign the data, and use this signature and the data as a token. Because other people don't know the key, I can't forge the token.

I will not save this token. When Xiao F sends this token to me, I will use the same HMAC-SHA256 algorithm and the same key to calculate the signature of the data again, and compare it with the signature in token. If it is the same, I will know that Xiao F has logged in and can directly access Xiao F's user id. If it is not the same, the data part must have been tampered with. I told the sender: sorry, there is no authentication.

The data in Token is saved in clear text (although I can encode it in Base64, but it's not encrypted), and it can still be seen by others, so I can't keep sensitive information like passwords in it.

Of course, if a person's token is stolen by others, there is nothing I can do about it. I will also think that the thief is a legitimate user, which is actually the same as a person's session id stolen by others.

In this way, I don't save session id, I just generate token, then verify token, and I use my CPU computing time to get my session storage space!

Get rid of the burden of session id, it can be said that nothing is light, my machine cluster can now easily do horizontal expansion, user visits increase, just add machines directly. This stateless feeling is so good!

Cookie

Cookie is a very specific thing, which refers to a kind of data that can be stored permanently in the browser, and it is only a kind of data storage function implemented by the browser.

Cookie is generated by the server and sent to the browser. The browser saves the cookie as kv to a text file in a directory, and the next time the same website is requested, the cookie will be sent to the server. Because cookie exists on the client, browsers have imposed restrictions to ensure that cookie is not used maliciously and does not take up too much disk space, so the number of cookie per domain is limited.

Session

Session is literally a conversation. This is similar to talking to a person. How do you know that you are talking to Zhang San instead of Li Si? The other party must have some characteristic (equal in appearance) that indicates that he is Zhang San.

The same goes for session, where the server needs to know who is currently sending the request to itself. To make this distinction, the server assigns a different "identity" to each client, and then the client carries this "identity" every time it sends a request to the server, and the server knows who the request comes from. As for how the client saves this "identity", there are many ways. For browser clients, everyone defaults to cookie.

The server uses session to temporarily save the user's information on the server, and the session will be destroyed after the user leaves the site. This method of storing user information is more secure than cookie, but session has a drawback: if the web server does load balancing, the session will be lost when the next operation is requested to another server.

Token

Token-based authentication can be seen everywhere in the Web world. In most Internet companies that use Web API, tokens is the best way to handle authentication under multi-user environment.

The following features will allow you to use Token-based authentication in your program

Stateless, extensible

Support for mobile Devic

Cross-program call

Safety

Bosses who use Token-based authentication

Most of the API and Web applications you've seen use tokens. For example, Facebook, Twitter, Google+, GitHub, etc.

The Origin of Token

Before introducing the principles and advantages of Token-based authentication, take a look at how previous authentication is done.

Server-based authentication

We all know that the HTTP protocol is stateless, which means that the program needs to verify each request in order to identify the client.

Prior to this, the program identified the request by the login information stored on the server. This approach is generally done by storing Session.

With the rise of Web, applications, and mobile devices, this authentication approach has gradually exposed problems. Especially in terms of scalability.

Some problems exposed based on server authentication

Seesion: each time an authenticated user initiates a request, the server needs to create a record to store information. As more and more users make requests, the memory overhead increases.

Scalability: using Seesion to store login information in the server's memory is accompanied by scalability issues.

CORS (cross-domain resource sharing): when we need to use data across multiple mobile devices, cross-domain resource sharing can be a headache. Requests can be prohibited when using Ajax to grab resources from another domain.

CSRF (cross-site request forgery): when users visit a bank website, they are vulnerable to cross-site request forgery and can be used to visit other websites.

Among these problems, extensible rows are the most prominent. Therefore, it is necessary for us to find a more effective way.

Verification principle based on Token

Token-based authentication is stateless, and we do not store user information in the server or Session.

This concept solves many problems when storing information on the server side.

NoSession means that your program can add or subtract machines as needed without worrying about whether the user is logged in or not.

The process of Token-based authentication is as follows:

The user sends the request with a user name and password.

Program verification.

The program returns a signed token to the client.

The client stores token and uses it each time to send a request.

The server validates the token and returns data.

Token is required for each request. The token should be sent in the header of the HTTP to ensure that the Http request is stateless. We also set the server property Access-Control-Allow-Origin:* so that the server can accept requests from all domains.

The main thing is that when the ACAO header is marked (designating) *, it must not carry certificates such as HTTP authentication, client SSL certificate and cookies certificate.

The idea of realization is:

The user logs in to verify and returns Token to the client after the verification is successful.

The client receives the data and saves it on the client.

Each time the client accesses the API, it brings the Token to the server.

The server side uses filter filter to check. Request data is returned if the verification is successful, and error code is returned if the verification fails.

When we authenticate the information in the program and obtain the token, we can do a lot of things through this Token.

We can even create a permission-based token and pass it to third-party applications that can access our data (of course, only on specific token that we allow).

Advantages of Token

Stateless, extensible

The Tokens stored on the client is stateless and can be extended. Based on this stateless and non-storage of Session information, the load balancer can transfer user information from one service to another server.

If we save the authenticated user's information in Session, each request requires the user to send authentication information to the authenticated server (called Session affinity). When the number of users is large, it may cause some congestion.

But don't worry. These problems are easily solved after using tokens, because tokens itself hold the user's authentication information.

Security.

Sending a token in a request instead of sending a cookie prevents CSRF (cross-site request forgery). Even using cookie to store token,cookie on the client side is only a storage mechanism rather than authentication. By not storing the information in Session, we have less operations on session.

Token is time-limited, and the user needs to revalidate after a period of time. We don't necessarily have to wait for token to expire automatically. Token has the operation of withdrawing. Through token revocataion, you can invalidate a specific token or a group of token with the same authentication.

Expandability

Tokens can create programs that share permissions with other programs. For example, you can associate a casual social account with your main account (Fackbook or Twitter). When logging in to the Twitter through the service (we Buffer this process), we can attach these Buffer to the data stream of the Twitter (we are allowing Buffer to post to our Twitter stream).

When using tokens, you can provide optional permissions to third-party applications. When users want another application to access their data, we can get the tokens of special permissions by creating our own API.

Multi-platform cross-domain

Let's talk about CORS (cross-domain resource sharing) in advance. When we extend applications and services, we need to get involved in a variety of devices and applications.

Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.

As long as the user has an authenticated token, data and resources can be requested on any domain.

Access-Control-Allow-Origin: *

When creating a token based on standards, you can set some options. We will describe it in more detail in subsequent articles, but the standard usage will be reflected in JSON Web Tokens.

The most recent programs and documentation are provided to JSON Web Tokens. It supports many languages. This means that you can really convert your authentication mechanism in future use.

The above is all the content of the article "what is the difference between cookie, session and token". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.