A brief discussion on where the token generated by node using jwt should be stored

A: Usually stored in the client.

jwt, or JSON Web Token, is an authentication protocol that is generally used to verify the identity information and identity permissions of a request.

When I was browsing a certain website this morning, I met a classmate who was asking this question. He was very curious about the storage location of jwt. I happened to be studying this topic some time ago, so I'm not shy about answering this question without being invited.
At first, I was also curious about how to save this token, and I almost wanted to use redis to store this token.

Later, I found out through some research that the server does not need to save this token. The client just needs to save it, no matter what method is used, you can even ask the user to write a note and put it in their pocket!

So how does this token work?

Let’s first talk about operations that require server-side storage, which is the traditional session approach.

First, to log in the user, you need to maintain a login table on the server. This login table can be placed in the cache or in the database.
When the user logs in, the user information is written into the login table, and then a login id, also known as a session, is derived. This session is returned to the client so that the client can bring up this information the next time it requests.

For the front-end guys, this process is usually imperceptible. The back-end guys use an http header field called set-cookie to write the data into the browser cookie themselves. Then when making a request, the browser will write the cookie into the request header itself.

When the client requests to enter the server, the server obtains the session in the cookie, then searches the login table for user information, verifies user permissions, and then completes normal business interaction.

Well, now I don’t want to maintain a login table for various reasons. What should I do?
It’s simple. Just send the user information to the client and let the client bring the user information every time. In this way, when a request comes in, you don’t even need to check the table, you can directly know which user is making the request.

But in this way, the user's information will be exposed. The middlemen like this kind of straightforward request the most. They will just take a stool and sit on your server port for a few days, and all the relatives in your database will be clearly exposed to others.

This definitely won’t work, so what should we do?

Just add a password and confuse it. This way, when the guys get your token, they will be confused for a while and will most likely walk away carelessly, leaving only a small number of guys who are well prepared (KPI) to struggle to crack it.

Once you decrypt it on the server, you get the user information. Similarly, you also write the expiration time into the ciphertext. If it expires, it will jump to the login page with a 401 error. In this way, a solution that does not require back-end storage of login credentials is developed.

This is the most basic working principle of jwt: the identity information is handed over to the client for safekeeping.

The token generated by jwt consists of three parts: header, payload, and signature, which are separated by a decimal point ".".

Header, that is, the header information, describes the basic information of the token and is in JSON format:

{
    "alg":"HS256",
    "typ":"JWT"
}

alg represents the encryption algorithm used to generate the signature part, and typ indicates that the token is of jwt type.

Payload is your user data, also in json format. However, JWT does not recommend putting sensitive data in it, because in the specification, the payload is the same as the header, and is only base64 encoded once and displayed on the token.

Signature is the signature of this token. Usually it is a string generated by encrypting the previous header and payload together with a private key string you define yourself.

As mentioned before, jwt only base64 encodes the contents of the payload, so it is very easy for attackers to change your content. However, they don’t know your private key, so they cannot generate the correct signature after the change. They use encryption to verify the header.payload of the request again, and find that it does not match the signature. At this time, you can clearly know that someone is causing trouble, and directly return a 500 to pretend that the server is down.
If you want to be more secure, it is recommended to use the https protocol for request communication throughout the process.

Of course, now that you understand how this works, it's not impossible to come up with your own disgusting specifications, for example, encrypt the payload again and then gzip it, etc.

So, what are the benefits of using jwt?

The first point is that the server does not need to maintain a login table, which saves space, especially when there are many users.
The second point is that expansion is simple, provided that you do not cause trouble and honestly abide by the JSON format to express your content.
The third point is that it is stateless. As long as the server supports parsing, it can conduct business. There is no need to set up a special mechanism to share sessions and add machines.
Fourthly, it supports a variety of clients and can be played even without supporting cookies.
The disadvantage is that these data must be brought back and forth every time a request is made, which will definitely increase the request content. Moreover, every time a request comes in, you have to verify it, encrypt the header and payload and verify the signature, which will also increase the request processing time. Compared with traditional operations, this is actually a trade-off between time and space. In the end, it depends on your choice.

This is the end of this article about where the token generated by node using jwt should be stored. For more information about where the token generated by jwt should be stored, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!