A: Usually stored in the client.

JWT, or JSON Web Token, is an authentication protocol used to verify the identity information and permission of requests.

In the morning, when I was shopping somewhere, I met a student asking this question and was curious about the storage location of JWT. Just some time ago in learning this content, do not invite, brazen strong answer.

At the beginning, I was also curious about how to store this token, and almost wanted to set up a Redis to store this token.

Later I looked up the information and found that the server could not save this token. You just need the client to save it, no matter how you keep it, even if you let the user write a note in their pocket!

So how does this token work?

Let’s start with the operations that require server storage, the traditional session practice.

To do user login, you need to maintain a login table on the server. This login table can be stored in the cache or in the database.

When a user logs in, the user’s information is written to the login table, and then a login ID, called a session, is exported, and this session is returned to the client for the next time the client requests this information.

This process is usually unconscious to your friends on the front end, and your friends on the back end use an HTTP header field called set-cookie to write the data themselves into the browser cookie. Then, when the request is made, the browser itself writes the cookie into the request header.

When the client requests to enter the server, the server gets the session in the cookie, and then checks the user information in the login table to verify user permissions, and then normal business interaction can be completed.

Now I don’t want to maintain a login form for all sorts of reasons.

Simple ah, directly send the user information to the client, let the client bring the user information every time, so that when the request comes in, even do not have to look up the table, directly know which user is requesting.

But this way, the user’s information is exposed, the middleman, love this kind of blunt request, they just take a stool to sit on your server port, sit for a few days, your database of the family cousin will be found.

That’s not gonna work. So what?

Add a cipher and then be confused, so that the old man will be confused when he gets your token, and most of the time he will go away carelessly, leaving only a few KPI’s in search of cracking.

As soon as you decrypt it on the server, you get the user’s information. Similarly, you write the expiration date into the ciphertext and jump to the login page when it expires. Thus, a solution that does not require back-end storage of login credentials is created.

This is how JWT works at its most basic: it hands over identity information to the client for safekeeping.

The token generated by JWT consists of header, payload, and signature. The three parts are numbered with a decimal point. Separated.

  • Header, also known as the header information, is the basic information that describes the token. It is in json format: 
    {
    "alg":"HS256"."typ":"JWT"
}
Copy the code

    algThe signature is the encryption algorithm that generates the signature.typIndicates that the token is of JWT type.

  • Payload is your user data, and it’s also a JSON format. The JWT does not recommend putting sensitive data in the token. Payload, like header, is only encoded once in Base64 and displayed on the token.
  • The signature is the signature of the token. It is a string generated by encrypting the header and payload along with the private key string defined by you.

JWT only base64 encodes the content of the payload, so it is easy for attackers to change the content of the payload. If you do not know your private key, you cannot generate the correct signature. If it doesn’t match signature, you’ll know for sure that someone is up to something and just return 500 and pretend the server is down.

For greater security, you are advised to use HTTPS for request communication throughout the process.

Of course, you already know how this works, so you can make up your own disgusting specifications, like, multiply payload again and gzip it and so on.

So, what are the benefits of using JWT?

The first point, of course, is that the server does not need to maintain a login table, saving space, especially if there are many users.

Second, it’s easy to expand, as long as you don’t mess around and stick to the JSON format to express your content.

Third, stateless, as long as the server supports the resolution, business can be carried out, there is no need to set up a special mechanism to share the session, which is convenient to add machines.

Fourth, support a variety of clients, do not support cookies can also play.

The disadvantage, of course, is that each request to bring these data, must be to increase the content of the request. In addition, every time a request comes in, you need to check the header and Paylaod for encryption and signature, which increases the processing time of the request. Compared with traditional operation, it is a tradeoff between time and space. In the end, it depends on your choice.