It’s enough to read this article about authentication

Liu Niping: Front-end engineer of Wedoctor Front-end Technology Department. Raise fish raise flowers raise dog, stay up late dance disco drink. After half a life away, I returned with three years of front-end work experience.

The first chapter

The birth and characteristics of Cookie

As we all know, the Web server is stateless, stateless means that the server does not know what the user did in the last request, each request is independent of each other, and the customer information only comes from the public information carried by each request, or saved by the server itself and can be used by all requests. Therefore, in order to track the status information requested by users, such as recording the shopping cart history of users shopping online, cookies came into being. When the server responds to the client request, it will push a Cookie to the client, which records some information on the server. The client carries the Cookie in the subsequent request, and the server can judge the context of the request according to the Cookie.

Cookie is a means of transition from stateless to state.

Taking login as an example, a user enters an account name and password and sends a request to the server. The server generates a Cookie and sends it to the browser. The browser saves the Cookie in k-V format to a text file in a directory. The server verifies whether the received Cookie is consistent with the Cookie on the server. If the Cookie is inconsistent, the authentication fails. That was the original idea.

The Cookie stored in the browser is located as shown in the figure below



The principle of Cookie determines its characteristics as follows:

1, stored in the client, can be tampered with, not safe

2. Its content will be transmitted with HTTP interaction, affecting performance. Therefore, the data that Cookie can store should not be too large, the maximum is 4KB

3. A browser can store no more than 20 cookies for a website, while the browser is generally only allowed to store 300 cookies

4. Mobile terminal is not friendly to Cookie support

5. In general, plain text is stored, objects need to be serialized before they can be stored, and deserialization is required for parsing

Cookie sharing between secondary domain names

Again, take the login Cookie example, for example, there are now two secondary domain names, http://a.xxx.com(domain name A) and http://b.xxx.com(domain name B). Is the login Cookie of domain A available under domain B? By default, only the server of domain NAME A can get the Cookie generated in the server of domain name A. Other domain names cannot get the Cookie. This is the host-only Cookie.

But the server can define its domain by explicitly declaring the Cookie’s domian, as shown in the example of set-cookie setting the domain of the login Cookie of domain A to http://xxx.com (their common top-level domain name), Set path to ‘/’, set-cookie: name=value; domain=xxx.com; Path = ‘/’, domain name B can be read. In the new specification RFC6265, the value of domain ignores any leading points, that is, **xxx.com** and **.xxx.com** can be used in subdomains. SSO(single sign-on) is also implemented based on this principle. For example, there are two domains, a.b.e.f.com.cn (domain 1) and c.d.e.f.com.cn (domain 2). Domain 2 wants to read the Cookie of domain 1. What domain can domain 1 declare? The answer is.e.f.com.cn or.f.com.cn. Browsers cannot accept cookies with domian as.com.cn, because if the Cookie field can be set to a suffix, it would be Canyon Brawl. Set-cookie: mykey= myValue1; domain=e.f.com.cn; Path = ‘/’ domain name 2 Set set-cookie: mykey=myvalue2; domain=e.f.com.cn; Path = ‘/’ then the value of mykey in this field will be overwritten as myValue2. It is easy to understand that the Cookie’s mykey is unique in the same field. In general, we need to reduce unnecessary data transfers and save bandwidth by setting the right domain and path.

Cookie-session mechanism

With the development of interactive Web applications, the size of the Cookie and the browser to store cookies to limit the number of the restrictions, we must need more powerful space to store large amounts of user information, such as we the site who is logged in, who joined the goods shopping cart and so on, the server to keep the user’s information, must even more Cookies, of course, don’t work. So what to do? Imagine that we are looking for a space on the server side to store the state information of all user sessions, and assign each user a different “id”, namely the sessionId, and then push this sessionId to the browser client to store the current state in cookies. The next request only needs to carry the sessionId, the server can go to that space to search for the user corresponding to the id. ** This can solve the Cookie limitation problem without exposing user information to the client, greatly increasing practicality and security.

So where do you store user information? Can it be stored directly on the server? If it exists in the server, 1, this is a huge cost to the server, severely limits the server’s ability to scale. 2. Assuming that the Web server is load balanced and user USER1 logs in to the system through machine A, then if the next request is forwarded to another machine B, there is no user information stored on machine B, so the sessionId cannot be found. Therefore, sessionids should not be stored on the server. At this point redis/Memcached is used to solve the problem, which can simply be thought of as a cached database. When we centrally store the sessionId in a separate cache server, all machines go to the cache system to obtain user information and authentication according to the sessionId. Then the problem will be solved.

Flowchart of cookie-session working principle

Do you see a problem with this approach based on how it works?

That increases the likelihood of single sign-on failures, and if the session machine dies, so does the entire login. However, generally in a project, the machine responsible for session is also a cluster of multiple machines for load balancing to increase reliability.

Consider: if the server is restarted, will user information be lost? Redis and other cache servers also have a cluster. If a service restarts, it will look up user information from other running servers. What if all servers crash in a real time? The general strategy is that user information stored in memory is periodically flushed to the host’s hard drive for persistent data, and if it is lost, it will only be lost within a few minutes of the restart.

Cookie – session limitations

1, rely on a Cookie, a user can disable cookies on the browser end 2, does not support across the compatible app etc. 3, the business system to find user information request cache server, making increased memory overhead, server stress 4, the server is a state, if there is no cache server, expansion is very difficult, Frantically replicate the sessionIDS on multiple servers. 5. Single sign-on (SSO) may fail

The second chapter

So we’re going to talk about CASCentral Certification Service), which is the standard process for single sign-on. It uses a separate system for authentication, hereafter known as the SSO system.

In fact, the process of single sign-on is the same as cookie-session mode, which means that each subsystem has a complete set of cookie-session mode, plus a set of cookie-session mode SSO system.



When a user accesses system A and needs to log in, he/she jumps to SSO system. After passing account and password authentication in SSO system, SSO server saves session, and generates a sessionId and returns it to SSO browser, which writes cookies in SSO domain. System A uses the ST to request the SSO system for verification. After the verification is successful, the server of system A writes the login status into the session and plants cookies in the domain of system A. When system A performs login authentication, it is the authentication in the same domain.

When the user accesses system B and jumps to SSO to log in, he finds that SSO has logged in. SSO generates an ST and carries the ST to system B. System B uses the ST to request SSO to perform verification. The server of system B writes the login status to the session and sets cookies in the domain of system B. It can be seen that system B does not need to log in again in this process.

The Oauth2 authorization mechanism will not be expanded here, but the idea is to let system B jump from system A when it jumps to SSO system. The session information carrying system A jumps to SSO and is redirected back to system B.

For Oauth2, please refer to Nguyen Yifeng’sOAuth 2.0 in four ways”.

The third chapter

We’ve already analyzed the limitations of cookie-session, but is there a more radical solution? Since the existence of SSO authentication system increases the possibility of single point of failure, should we not have it at all? This is the idea of decentralization, that is, eliminating the cache servers used to store and verify user information and verifying it in a different way in their own systems. To put it simply, all session information is encrypted into cookies and sent to the browser, and CPU computing power is used to exchange space.

Json Web Token mode

The server does not save the sessionId. After a user logs in to the system, the server sends a token to the user. The next time the user accesses the server through Http requests, the token is sent to the server through Http headers or URLS for verification. In order to prevent others from forging, we can add the data to a key that only we know, make a signature, and send the data and the signature together as a token. This way we don’t have to save the token, because the token sent to the user already contains the user’s information. When the user requests again, I use the same algorithm and key to encrypt the data in the token. If the encrypted result is consistent with the signature in the token, we can conduct authentication and obtain the user information.



For the server, it is only responsible for generating tokens and then verifying tokens, and there is no need for additional cache servers to store a large number of sessions. In the face of increasing traffic, we only need to expand the capacity of servers with large access demands, which is more saving than expanding the entire user center server.

If someone tampers user information, but the key is not known, the signature in the token will be inconsistent with the signature calculated by the client after tampering, and authentication will fail. Therefore, there is no need to worry about security issues.

Regarding the timeliness of token, it is done like this: the first login generates a token according to the account password, and each subsequent request, the server updates the timestamp and sends a new token, and the client replaces the original token.

What are the advantages and disadvantages of JWT

Disadvantages 1. JWT mode login is actually a false login failure, because it is just an illusion formed by the browser side to clear the token. If you use the previous token, you can still login successfully as long as it does not expire. Security depends on the key. Once the key is exposed, 3. The generated data is long and consumes more traffic

Advantages 1. Independent of cookies, cross-application can be supported on mobile devices 2. Great compared to cookie-session without single sign-on extension 3. The server remains stateless and does not need to store user information in the server or Session 4. For single sign-on, the mode of constantly sending verification requests to SSO site saves a large number of requests to the online diagnosis and treatment platform of Wedoctor Internet hospital for quick consultation, and you can find a top three doctor in 3 minutes.