With Bytedance, the front end rarely touches anything beyond the HTTP request, and the SDK for login is well packaged, so this article is a simple study of the record.

Why is there such a thing as login

First of all, this is because HTTP is a stateless protocol. Stateless means that the server does not hold any data between requests. It means that after you talk to a person, they forget about you. So, login is about finding a way for the server to recognize you across multiple requests, rather than having to carry identifying information like a user name or password with each request. From the time you log in to the time you log out, the server maintains a data structure that recognizes the user’s information. Broadly speaking, this process is called a session.

There are two common logins

It suddenly occurred to me that after reading a lot of questions on the Internet, I think you should distinguish between two concepts: session in its broad sense and session in its narrow sense

Session in broad sense:Session is the process from successful login to logout. During this process, the client and server maintain the state of maintaining login. There is no requirement on how to maintain this state of login.

Narrow session:The narrow sense of session is that after a successful login, the server side stores some necessary user information. This part of the user information on the server side is called session, which is the implementation method of the first login.

Server session+ client session ID

Let’s start with the graph:



In detail, this is mainly a few processes:

  1. The client accesses the /login interface with the user name and password. After receiving the user name and password, the server verifies the user name and password. If the verification is correct, a sessionId and session mapping relationship are stored on the server


  2. The server returns a response and sets the sessionId as a set-cookie on the client, so that the sessionId exists on the client. It is important to note that keeping sessionids in cookies is not a mandatory solution, but it is common practice to do so, and requests that match domain and path will automatically include cookies, eliminating the need for manual blocking.
  3. When a client initiates a non-login request, the server uses the session ID in the cookie to find out who made the request.

token

As mentioned earlier, the sessionId method is to maintain the user state information on the server, and the token method is to encrypt the user state information into a string of tokens and pass them to the front-end, and then each time the request is sent, the token is passed back to the server. After receiving the request, the server parses the token and verifies the information.


Therefore, the most essential difference with the first login method is that the computing time of parsing the token is exchanged for session storage space

The common encryption method in the industry is JWT (JSON Web Token). The specific format of JWT is shown in the figure below:



To briefly introduce JWT, it mainly consists of three parts:

The header head {"alg": "HS256"."typ": "JWT"} payload {"sub": "1234567890"."name": "John Doe"."iat": 1516239022,
  "exp": 1555341649998} signature Indicates the signatureCopy the code
The header describes the encryption algorithm and the token type. The type is usually JWT.

Payload contains user information, which is the information that needs to be maintained in the server session in the first login method.

Signature is the signature of the first two parts, which can also be interpreted as encryption. The implementation requires a secret, which only the server knows, and uses the algorithm in the header to encrypt as follows: 

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)Copy the code
JWT = Base64URL (header) + “.” + Base64URL (payload) + “.” + signature


JWT can be returned in response or in cookie. These are the specific return methods, which are not important.

When a client initiates a request, the official recommendation is placed in the HTTP header: 

Authorization: Bearer <token>Copy the code

This can indeed solve the problem of cookie cross-domain, but the specific place or according to the business scenario, there is no set rules.

Problems with the two login schemes

The session way

  1. Session mode because the session information will be maintained on the server, it is easy to use a single server. If it is multiple servers, the session information needs to be synchronized between servers, which makes the service scale-out inconvenient.
  2. The number of sessions increases as more users log in, and the storage increases a lot.
  3. The sessionId stored in session+cookie may cause CSRF attack. The common way is to use cSRF_Token to solve the problem

JWT way

  1. The expiration time of JWT needs to be set according to the service. Moreover, once JWT is distributed, the backend cannot forcibly invalidate it

The latter

Clear the concept, a relaxed

——————————————–

Welcome to pay attention to my public number, front-end subarchaea, do front-end, not only do front-end.