preface

Recently, I made a video playback project when I left my job at home. I originally wanted to deploy it to the server, but the result was that ali server only had 2G2 core, so I had to deploy it to the virtual machine. After the whole project was finished, I wrote some comments on my blog during the summary

In the projects I’ve worked on, I’ve concluded that we need to know about sessions and cookies before we talk about login design

session

Because the HTTP protocol is stateless, we cannot know the state of the client when accessing the server, so there are session and cookie. Session is stored on the server, through which we can know the session state of the client. Session corresponds to HttpSession in Java. When getSession is created, a session will be created, and the associated sessionId will be generated. The session will respond with the HTTP, and the next request will be sent with the sessionId in the HTTP header. The server gets the corresponding ID based on the session ID and gets the corresponding session. Because sessions are stored on the server, problems may occur: 1. In cluster mode, session transfer synchronization is required. 2.

cookie

The HTTP protocol itself is stateless. What is stateless? The server cannot identify the user. A Cookie is actually a small piece of text information (in key-value format). The client makes a request to the server, and if the server needs to record the user status, it issues a Cookie to the client browser using response. The client browser saves the Cookie. When the browser requests the site again, the browser submits the requested URL along with the Cookie to the server. The server checks the Cookie to identify the user’s state.

Now that we know about sessions and cookies, let’s look at the concept of JWT

Log on to design

In the design scheme, there are two kinds, one is related to session, the other is related to cookie, let’s introduce it in sequence:

Design of the session

If we use session as login mark, there will be problems of memory consumption and cluster consistency. To solve this problem, we can store sessionId in Redis as token. The flow chart is as follows:

When a browser request comes to visit the server, it first goes through the gateway. In the gateway, we make a filter to filter the request to see whether the request carries a token. If the request carries a token, we check whether the request exists in redis. If the token does not exist or does not exist in redis, it indicates that the session is out of date and you need to log in again. In this case, the front end will jump to the login page and the request will access the user service. After verifying the user name and password, httpsession.getSession () is used to obtain the session. Then the business name +sessionId is used as the key, and the user information is stored in redis as the value. The sessionId is returned to the front end as the token, and the front end will bring the sessionId when accessing next time. In this way, we can determine whether the user logs in. Session is transferred synchronously, which reduces the pressure on the server and the traffic volume of the user service. There is no need to check whether the user name and password are correct every time. The disadvantage is that although the session is saved in Redis, it undoubtedly increases the complexity of the system. But mobile often doesn’t have cookies, and if the browser only uses cookies, you need to add a sessionId after the URL.

Before we look at cookie-based login authentication, we need to take a look at JWT

JWT

IO /, the entire format is JSON format, JWT consists of three parts:

Header (the header includes the type of token (eg: JWT) the hash algorithm used (eg: RSA))

Load (a place to store valid information, such as the issuer, expiration date, or can be customized (eg: user’s basic information))

Signature (Signature, this part prevents JWT from being tampered with, this part encodes the first two parts with base64URL)

Asymmetric encryption algorithm

Encryption and decryption use different secret keys, one for public and one for private. Public key encrypted information, only the private key can decrypt. The private key encrypts information that only the public key can decrypt. Common asymmetric encryption algorithms are RSA and ECC

Cookie design

This is the login authorization I used when I did the previous project. The security of cookie has always been a problem. Although setting HttpOnly to true can prevent JS script from stealing information, we still need to encrypt token for security to ensure the security of user information.

The public key is stored in the configuration file of each service except the authorization service, and the corresponding private key is stored in the authorization service. When the request comes through the gateway, the filter in the gateway will decrypt the token using the public key. If the decryption succeeds, the expiration time of the token in the cookie will be updated and 200 will be returned. If decryption fails, return to login interface, log in, go to authorization service, come to authorization service, verify user name and password first, then use JWT tool, use private key to encrypt user information, generate JwtToken, finally write token cookie, set expiration time, and set httpOnly to true. Prevent JS scripts.