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

This article mainly explains "how to understand cookie, session and token". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to understand cookie, session and token".

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.

You can 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

Application scenario: log in to the website. After entering the user name and password to log in today, you will log in directly in many cases when you open it the next day. One of the mechanisms used at this time is cookie.

Generally speaking, it is some website-related information stored locally after visiting some websites, and some steps are reduced the next time you visit. More accurately, Cookies is a small piece of text stored by the server on the local machine and sent to the same server with each request, and it is a solution to keep the state on the client side.

The main contents of Cookie include: name, value, expiration time, path and domain. You can see it by using Fiddler to grab the package. For example, if we open a website of Baidu, we can see that Headers includes Cookie, as follows:

BIDUPSID: 9D2194F1CB8D1E56272947F6B0E5D47E PSTM: 1472480791 BAIDUID: 3C64D3C3F1753134D13C33AFD2B38367:FG ispeed_lsm: 2 MCITY:-131: pgv_pvi: 3797581824 pgv_si: s9468756992 BDUSS: JhNXVoQmhPYTVENEdIUnQ5S05xcHZMMVY5QzFRNVh6SzZoV0xMVDR6RzV-bEJZSVFBQUFBJCQAAAAAAAAAAAEAAACteXsbYnRfY2hpbGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALlxKVi5cSlYZj BD_HOME: 1 H_PS_PSSID: 1423 "21080" 17001 "21454" 21408 "21530" 21377 "21525" 21193 "21340 BD_UPN: 123253 sug: 3 sugstore: 0 ORIGIN: 0 bdime: 0

Key, value form. The expiration time can be set, if not, the browser is turned off and disappeared, stored in memory, otherwise it will be stored on the hard disk according to the set time, and it will be cleared automatically after expiration. For example, after the switch is closed and then opens the browser, he will still exist, the former is called Session cookie and transient cookie, and the latter is called Persistent cookie and permenent cookie. The path and domain are the corresponding domain names, so the cookie of a website cannot be used by b.

Deficiency:

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

Application scenario: one scenario of session is a shopping cart. After adding items, the client knows which items have been added, but how does the server judge it, so it also needs to store some information. Session is used.

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 wears 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.

There is a HashTable-like structure for storing user data on the server. The first time the browser sends a request, the server automatically generates HashTable and Session ID to uniquely identify the HashTable and sends it to the browser in response. The second time the browser sends the request, the Session ID from the previous server response will be sent to the server together with the request. The server will extract the Session ID from the request and compare it with all the saved Session ID to find the corresponding HashTable of this user.

There is usually a time limit for this value, which is destroyed after the timeout. The default is 30 minutes.

When the user jumps between the Web pages of the application, the variables stored in the Session object are not lost but persist throughout the user session.

The implementation of Session has something to do with Cookie. A session id is generated when a connection is established, and several pages are opened. Here, Cookie is used. The session id is stored in Cookie, and the Session id can be identified each time you visit it.

The difference between Cookie and Session

Storage data: session can store arbitrary java objects, while cookie can only store String objects.

One is on the client side and the other is on the server side. Because cookie is on the client side, it can be forged, which is not very secure.

Too much Session will consume server resources, and large websites will have special Session servers. It is no problem for Cookie to protect its shortcomings.

The scope of domain support is different. The Cookie of the fire lock a.com can be used under a.com, while the Session of www.a.com cannot be used in api.a.com. The solution to this problem is JSONP or cross-domain resource sharing.

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

For those 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. 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 Tokens

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, but the standard usage is 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.

Thank you for reading, the above is the content of "how to understand cookie, session and token". After the study of this article, I believe you have a deeper understanding of how to understand cookie, session and token, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.