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

This article mainly explains "analyzing Session and Token". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "analyze Session and Token".

01.Cookie

Is a mechanism for saving user information on the client (browser); Cookie is generated by the server and sent to the browser, and then the browser stores the Cookie in a directory on the client in the form of key-value pairs; there are some differences in the storage size of each browser, which generally does not exceed 4KB

When the next request is made, the Cookie is sent to the server, which parses and verifies the information in the Cookie.

For example, if you join a company, you will be given a work card with your name, job number, department and other information on it. When you enter the workplace, you can go in and out with work card.

But Cookie cannot be used across domain names; it's like if I go to your company with our company's work card, the security guard will definitely not let me in.

02.Session

It is saved on the server side and can be used to record customer status.

For example, we often use Session to save the customer's basic information and permission information. After the user logs in for the first time, the server will create a Session and return the SessionID to the browser. The browser usually writes it to the Cookie, which is also called SessionCookie. When the browser visits again, you only need to find the Session from the server with the SessionID.

In addition, the SessionID does not have to be saved to Cookie, but for browser clients, the default practice is to put it in Cookie.

03.Cookie and Session

With regard to the difference between Cookie and Session, many students will reply: "Cookie is saved on the client side and Session on the server side." in fact, this idea is not comprehensive:

Cookie is a real thing, a very concrete thing, that is, a piece of data, while Session is an abstract concept, or pattern method, which has many implementation schemes.

For example, the implementation of Tomcat: save the state on the server side, then generate a JSESSIONID and put it in Cookie; after the request comes, query and verify the status on the server side with JSESSIONID.

04.Token

Of course, with the increase in the number of users, the number of Session stored on the server side is also increasing, which puts a lot of pressure on the server side. And if the program is deployed in a cluster or distributed way, the same user accesses server A for the first time and creates a Session, but the second request is sent to server B, but there is no previously created Session on server B. This is the problem of Session sharing in distributed architecture.

To solve this problem, we can synchronize Session between servers, or simply save Session to a third-party component, such as Redis, but either way, Session becomes a burden on the project.

At this time, the server will think, if only Session is not saved with me, send me the user name and password for the first time, and after the verification, I will give you a pass, and then the client will take this pass with you every time it requests.

The pass is token. Of course, the verification result needs to include client information, and the server needs to know who sent the request; it also needs to include time information, because the pass cannot be valid forever; the pass cannot be plaintext, otherwise there is a risk of being intercepted.

HMAC-SHA1:

Token = user_id | expiry_date | HMAC (user_id | expiry_date, k)

AES:

Token = AES (user_id | expiry_date, x)

RSA:

Token = RSA (user_id | expiry_date, private key)

05.SSO single sign-on

Some companies will build a unified login system (single sign-on). The client first goes to this system to obtain the Token, and then verifies that the Token can be used to access other systems. API Gateway can also provide similar functions. This is the case in our company. When the client accesses, obtain the Token from the gateway first, verify that it is passed before you can access the authorized interface, and then re-or Token after a period of time.

06.Token and Session

For session and token, there is no essential difference between them, both are encrypted strings and can be authenticated. Of course, there are some differences between token and session, such as token is easier to cross-domain, token is easier to control, and so on. In addition, token has greater advantages over session in authorization scenarios.

For example, I develop a website that allows Wechat users to log in, and the process for using token goes something like this:

When logging in to the website, jump to the Wechat login page

After the user enters the user name and password to log in to Wechat, give us a token

Users can use token on our website, and our site does not need to know your Wechat user name and password.

In short, if in the same site, token and session are not much different, if cross-site use, token will be more convenient.

Thank you for your reading, the above is the content of "analyzing Session and Token". After the study of this article, I believe you have a deeper understanding of the analysis of 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.