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

This article introduces the relevant knowledge of "what is Cookie,Session,Token". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Brief introduction:

Cookie:

Cookie calls it session tracking technology, which, as its name implies, tracks and records some state in a session. First of all, the so-called "session" refers to the process from the browser opening a website to visiting its other web pages until the browser is closed. Cookie can track and record the status of the client from the beginning to the end of a session. Cookie is a file that the server stores locally on the client. It is like an identity issued to the client by the server. With this ID, as long as the client carries it with him. The server will be able to identify us.

Session:

In computers, especially in network applications, it is called "session control". The Session object stores the properties and configuration information required for a specific user session. In this way, when the user jumps between the Web pages of the application, the variables stored in the Session object will not be lost, but will persist throughout the user session. When a user requests a Web page from an application, the Web server automatically creates a Session object if the user does not already have a session. When a session expires or is abandoned, the server terminates the session.

Token:

Token means "token" in Chinese. It is mainly used for authentication. Large websites such as Facebook,Twitter,Google+,Github are in use. Compared with the traditional authentication methods, Token has the characteristics of strong scalability and high security, so it is very suitable for Web applications or mobile applications.

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, just let each client to 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 oken 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.

In Session-based authentication, the server creates a Session for the user after the user logs in. The Session ID is then stored in the Cookie of the user's browser. When the user remains logged in, the Cookie is sent along with each subsequent request. Then, the server can compare the Session ID stored on Cookie with the Session information stored in memory or database to verify the identity of the user, and return the response information to the user client with the user's current state.

It should be easier to understand compared to the diagram below.

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.

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

Token characteristics

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

Stateless, extensible support for mobile device cross-program call security

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.

The following figure shows the principle of server-based authentication

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 in the client. Every time the client accesses the API, it carries 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-based verification

Stateless, extensible

The Token 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 Token, because Token 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

Token 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 Token, 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: *

Based on standards

When you create a Token, 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 Token.

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

This is the end of "what is Cookie,Session,Token". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.