First, the defects of session-based application development

In our traditional BS application development mode, session is used for state management, such as saving login, user, permission and other state information. The principle of this approach is roughly as follows:

  • After the user logs in, the status information is saved to the session. The server automatically maintains the sessionid and writes the sessionid to the cookie.
  • The cookie is automatically saved to the browser along with the HTTP response.
  • When the user sends the HTTP request again, the sessionID is brought back to the server along with the cookies
  • According to the sessionID, the server can retrieve the data saved in the session by the user.

Of course, cookies and sessionids are automatically maintained on the server and browser side throughout this process. Therefore, it is not perceived from the coding level, and the programmer can only perceive the access of session data. However, there are situations where this approach is not appropriate.

  • For example: non-browser clients, mobile phones, etc., because they do not have the browser to automatically maintain cookies.
  • For example, in distributed applications, the same application is deployed on hosts A, B, and C to implement load balancing. If one of the applications fails, the others can still work. Since sessions are stored in server memory, the three hosts must have different memory. If you log in to user A and access interface data to user B, there is no guarantee of session uniqueness and sharing.

Of course, we have solutions for all of the above cases (such as Redis shared session, etc.), which can continue to use sessions to save state. However, there is an alternative to using sessions, which is to develop stateless applications, and JWT is one such solution.

What is JWT?

I don’t want to use a fancy term to explain JWT (JSON Web Tokens). You can think of JWT as an encrypted interface access password that contains username information. So you know who you are? Or whether you can access the app?

  • First, the client needs to request a JWT token from the server, which is usually a login function. That is, a user name and password in exchange for a JWT token.
  • Carry the JWT token in the HTTP header when you access other interfaces on the system. The name of the header can be customized.
  • The server unchecks and verifies the user id in JWT, and loads the access permission, user information and other status information from the database based on the user id.

This is JWT and how it is used in application service development.

3. JWT structure analysis

The picture below is the screenshot when I decode using the online JWT decoding tool. Notice I’m using decode here, not decrypt.

From the figure, we can see that JWT is divided into three parts:

  • Header, which is usually used to describe the algorithm information used by JWT
  • Payload, which is usually used to carry some custom additional state information (importantly, the user identity). But note that this part can be decoded in clear text, so it should be the user id, not the user name or other user information.
  • Signature, this part is the signature of the first two parts of data, preventing the first two parts of data from being tampered with. You need to specify a secret key for signing and unsigning.

Is JWT safe?

A lot of friends see the above decoding file, will give birth to a question? You’ve parsed JWT, and JWT is so widely known, is it safe? Let me give you a simple explanation:

  • JWT is like a key to the lock in your house. Once the user loses the key, the home is not safe. In fact, the same with using session management state, once the network or browser is hijacked, it is not secure.
  • Signature is usually called a signature, not a password. For example: Tianwang cover ground tiger is a signature, baota town river demon is used to unsign. You know all the words, but only those who know them can use them. Of course the secret in JWT is not designed to be as simple as poetry.
  • The JWT server also keeps a key, the secret. Once the secret is lost, all users are not safe. So IT’s even more important for IT people to keep Secret secure.

How can JWT security be enhanced?

  • Avoid network hijacking because HTTP headers are used to pass JWT, so HTTPS transport is more secure. This avoids JWT leaks at the network level.
  • Secret is stored on the server side, so JWT is theoretically safe as long as the application server is not compromised. Therefore, ensure the security of the server.
  • So is it possible that the JWT encryption algorithm was breached? B: of course. However, to break the commonly used JWT algorithm, the only known method is brute force cracking, which is called “try password” in vernacular. Therefore, it is necessary to regularly replace secret and maintain the complexity of Secret. When the result of cracking comes out, your Secret has been changed.

On the other hand, no protocol or algorithm is safe if your server, or someone on your team, is compromised.

We look forward to your attention

  • I recommend the blogger’s series of documents: “Hand on Hand to teach you to learn SpringBoot Series – Chapter 16, Section 97”.
  • This article is reprinted with a credit (must be accompanied by a link, not only the text) : Antetokounmpo blog.