* * "Front-end storage" * * This involves an engine, a storage and an area, which is easy to send. The login interface directly returns to the front end, so the front end needs to find a way to store it.

There are many storage methods in the front end.

Yes, cookies. Cookie is also a kind of front-end storage, but compared with other ways such as localStorage, with the help of HTTP header and browser capabilities, the cookie front-end can be made unconscious. The general process is as follows:

"Configuration: Domain/Path"

Cookie are used to limit:: "spatial scope":: and pass through two levels: domain/path.

"Configuration: Expiration/Maximum Term"

Cookie can also be limited to one of:: "time range": "expiration time" and "maximum use time".

"Configuration: Security /HttpOnly"

Cookie can limit:: "usage"::.

* * *“HTTP header reads and writes cookies "* * Looking back, how does HTTP read, write and pass cookies and their configuration? Write "one (and only one)" Cookie to the browser with a Set-Cookie header returned by HTTP, and the format is cookie key value+configuration key value. For example:

What if I want to set more cookie at once? Give more Set-Cookie headers (duplicates are allowed in HTTP requests).

The browser uses the Cookie header of the HTTP request to send all cookies that meet the current "space, time and usage" configuration to the server. Because the browser has made a filtering judgment, it is not necessary to return the configuration content, just send the key value.

* * "front-end reading and writing cookies" * * The front-end can create cookies by itself. If the cookie created by the server does not add HttpOnly, congratulations, you can also modify the cookie given by him. Call document.cookie to create and modify cookies. Like HTTP, document.cookie can and can only operate one cookie at a time.

You can also read cookies by calling document.cookie. Like HTTP, you can read all non-HttpOnly cookie.

Now think back, what happened when you swiped your card?

This operation, in front-end and back-end authentication systems, is called session. Typical session login/authentication process:

* * "How to store the session" * * Obviously, the server only gives the cookie a sessionId and the specific content of the session (which may include user information, session status, etc.). ) I should have saved myself. There are several storage methods:

"Session Expiration and Destruction" * * is very simple, just destroy the stored session data. * * * * "Session Distributed Problem" * * Usually, the server is a cluster, and users will take a load balance when they request it, not necessarily to which machine. So once the user's subsequent interface request machine is inconsistent with his login request machine, or the login request machine is down, isn't the session invalid? Now there are several solutions to this problem.

However, the first method is usually adopted, because the second method is equivalent to castrating load balancing, and still does not solve the problem of "machine downtime required by users". * * "Session Processing under Node.js" * * The previous figure is very clear, and there are still many things to be done for the server to access cookie and sessions. In npm, there are already packaged middleware, such as express-session-npm, so the usage is not published. Here are its cookies:

The main realization of fast session npm is:

The maintenance of the session has caused great trouble to the server. We must find a place to store it, consider the problem of distribution, and even enable a Redis cluster for it alone. Is there a better way?

Looking back, a login scenario doesn't need to store much in the session, so why not just package it as a cookie? In this way, the server does not need to save, but only needs to check the validity of the "certificate" brought by the cookie every time, and can also carry some lightweight information. This method is usually called token.

The process of token is as follows:

* * "How to store client tokens" As mentioned in the previous cookie, cookies are not the only way for clients to store credentials. Because of its "stateless", the validity period and usage restrictions of token are wrapped in the content of token, which is less dependent on the management ability of cookie and more free for the client to save. But the mainstream way of web application is still put in cookie. After all, don't worry too much. "Token Expiration" * * So how do we control the expiration date of the token? It's simple. As long as the "expiration time" is put together with the data, it can be judged when verifying.

The coding method is rich and frugal. * * *“base64”* * * such as cookie-session-npm library on the node side.

By default, when I give him a userid, he will save it like this:

Eyj 1c2vyawqiojin0 = This is just base64 of {"userid": "abb"}. "tamper-proof"

Yes, it depends. If the token involves sensitive rights, we must find a way to prevent the token from being tampered with. The solution is to sign the token to identify whether it has been tampered with. For example, in the cookie-session-npm library, two configurations have been added:

In this way, there will be all kinds. Sig cookie, the value of which is calculated by {"userid": "abb"} and iAmSecret through encryption algorithm, such as HMACSHA256 (system. Security. Encryption) | Microsoft Documents.

Ok, now cdd can forge eyj 1c2vyawqiojin0 =, but can't forge the contents of sig, because he doesn't know the secret. * * "jwt" * * But the above practice increased the number of cookie, and the data itself did not have a standardized format, so the introduction of JSON Web token-jwt.io was born.

It is a mature token string generation scheme, which contains the data and signature we mentioned earlier. Why don't you see what JWT tokens look like?

How did this string of things come about? Look at the picture:

Type, encryption algorithm options, JWT standard data fields, you can refer to RFC 7519-JSON Web Token (JWT) node, which also has related library implementation: express-jwt-npm koa-jwt-npm.

Token, as the guardian of authority, the most important thing is "safety". The token used by the business interface for authentication is called an access token. The more privilege-sensitive the business, the shorter the validity period of the access token is, so as to avoid being stolen. However, too short a validity period will lead to frequent expiration of the access token. What if it expires? One way is to let the user log in again to get a new token, which is obviously not friendly enough. You should be aware that some access tokens may expire in a few minutes. Another way is to have another token, a token that generates access tokens specially, which we call refresh token.

With the refresh token, the request flow in several cases becomes like this:

If the refresh token has expired, you can only log in again.

Session and token are concepts with blurred boundaries. As mentioned earlier, refresh tokens can also be organized and maintained in the form of sessions. In a narrow sense, we usually think that session is an authentication scheme of "planted on cookie and data stored on the server", and token is an authentication scheme of "client can be stored anywhere and data is stored in token". The comparison between session and token is essentially the comparison between "the client saves cookie/places" and "the server saves data/does not save data". * * "Client saves cookie/places”* * * Saving cookies is convenient, but the problem is obvious:

Save it somewhere else, which can solve the scene without cookie; CSRF attack can be avoided by manual tape with parameters. "Server saves data/does not save data"

We already know that in the client/server authentication system under the same domain, the client carries the credentials that keep the login status for a period of time. When there are more and more business lines, more business systems will be scattered under different domain names, which requires the ability of "single sign-on, common to all lines", which is also called "single sign-on".

Simple, if the business systems are all under the same main domain name, such as tieba.baidu.com and wenku.baidu.com, it will be simple. You can directly set the cookie domain name as the main domain name Baidu.com, which is what Baidu has done.

For example, a well-known company like Didi owns domain names such as didichuxing.com, xiaojukeji.com and didiglobal.com, and such cookie are totally unavoidable. Only by "single sign-on, one size fits all" can it be truly single sign-on. In this case, we need an independent authentication service, usually called SSO. "The complete process from system A to system B, without login".

* * "Full version: consider the scene of the browser" * * The above process seems to be no problem. In fact, it is enough for many apps. But it may not work well in the browser. Look here:

For the browser, how to save the data returned under SSO domain, so as to bring it when visiting A? Browsers have strict restrictions on cross-domain, and methods such as cookie and localStorage have domain restrictions. This requires that only A can provide the ability to store credentials under the A domain. Generally speaking, we do this:

In the figure, we color-coded the domain name where the browser is currently located. Note the change of gray text description in the picture.

Thank you all.