Please stop using JWT for session management immediately



Recently, it has been found that many web application systems use JWT for session management. The reason is to avoid storing sessions on the server or to pursue independent control. I don’t know that there are huge security risks in using JWT for session management!

HTTP session management

Let’s talk about HTTP protocol first. As we all know, the feature of HTTP protocol is one question and one answer (one request and one response). Then, based on the HTTP protocol, a shopping website should realize the function of user login, adding goods to the shopping cart and finally paying the bill. In order to realize the above functions and identify that a series of operations are the same user, the simplest way is to send the account and password every time you operate the browser, so that the server knows which user added the goods to the shopping cart and finally paid the bill. This looks crude, and carrying an account and password in each request will greatly increase the risk of disclosure.

In order to reduce the number of times the account password is carried in the request, we introduce a session ID. When you log in to the shopping website with your account password (the first request), the server returns a session ID after passing the authentication. After that, you can add goods to the shopping cart or finally place an order. Anyway, you can carry this session ID with each subsequent request. Why can you identify which customer’s operation this is by carrying the session ID? Because the server associates the customer’s account information with the session ID sent to the client in this session, the association information between the session ID and the account is session data.

In the above example, session data is stored on the server. In fact, session data can also be stored to the client. According to the location of session data storage, there are two modes: server side session and client side session.

Server Side Session

The server side session mode is the most common, such as the previous example of shopping websites. In this mode, the client (browser) stores the session ID in local cookies. Its typical implementation is shown in the figure below:
Please stop using JWT for session management immediately
In the figure above, user a is an old user who has established a session. Session is stored in his cookies_ ID, the value is “Aa01”, and the session is carried in the request_ ID, which is received by the server through session_ ID query the corresponding data in the session database and use it in the program. New user is a new user who has just started a session. There is no session in his cookies_ ID, so the server generates a new session_ The ID is returned to him, and the 401 status code is used in the return to tell him to redirect to the login page for login. Subsequently, if the new user logs in successfully, the server will store his identity information in the session table and compare it with the session generated at the beginning of the session_ ID Association, so that subsequent requests are like the old user user a.

Client Side Session

The client side session mode may seem a little strange to you, but it is actually used a lot. For example, most web systems that use JWT for session management are client side session mode. The so-called client side session mode is to store the user’s session data on the client, so that the server is very free. The interaction process is roughly shown in the figure below:
Please stop using JWT for session management immediately
User a on the left in the figure above is an old user who has established a session, and his session is stored in his cookies_ Data, the value is the basic information of the current user, and the session is carried in the request_ Data, and the server parses the session after receiving the request_ Data information, which user’s request is known. The new user on the right is logging in to establish a session. After the server authentication is successful, a session will be generated_ Data information, which is returned to the client. Due to session_ The data is stored in the client. In order to prevent tampering, the server will process the generated session_ Data data is signed and even encrypted.

Server Side VS Client Side

The previous article introduced the respective principles of server side session and client side session, so which is better? Before comparison, set a benchmark, that is, onlyFunctionalityandSecurityInstead of comparing the original implementations of the two patterns.

Server Side Session


  1. The session data is stored in the server, which does not expose relevant information and has high security;
  2. Each request only needs to pass the session ID to reduce the traffic overhead;
  3. The server can easily revoke the session, control the number of concurrent sessions with the same account and other comprehensive session policy management;


  1. When the server is deployed in a distributed manner, it is necessary to increase the processing session data share.

    Client Side Session


  2. Distributed storage;


  1. The session data is stored in the client and carried in each request, increasing the risk of disclosure;
  2. Each request needs to deliver more data, increasing traffic overhead;
  3. It is inconvenient for the server to revoke the session and realize various session policy management;

From the above comparison, it can be seen that the two modes areFunctionalityandSecurityThe characteristics are just the opposite. The server side session mode has outstanding advantages, but why does the client side session mode still exist? The so-called existence is reasonable, because the client side session modeThe original implementation is simple! In client side session mode, the server does not need to centrally store session data, and naturally does not need to process the search of session data. Moreover, it is stored in the client separately, and the server does not need to consider session data sharing under distributed.
However, the original implementation of client side session mode is simple, which is not important for users, because users only use ready-made libraries and frameworks, as long as they have good support. Therefore, the server side session mode is more common than the client side session mode.

What is JWT?

First of all, the JWT (JWe, JWs) standard only designs an anti tamper token, not for session management.
Please stop using JWT for session management immediately
JSON web token (JWT) is an open data standard based on RFC 7519. It defines a loose and compact data combination method, using JSON   Object transmits information between applications (information encryption is JWe, signature is JWs). The JSON object can be authenticated and verified by digital signature. Generally, JWT can use HMAC algorithm, RSA or ECDSA’s public / private key to sign data. A JWT is usually composed of header, payload and signature. A “.” link is used between them. The format is shown in the figure above.

Defects of JWT

The JWT standard design looks very good, but it actually harbors evil intentions. Because of its design, many security problems are hidden. The details are as follows:

Reset null encryption algorithm defect

JWT supports setting the algorithm to “None”. If you do not set to turn off this function when using JWT library, any token is valid. The specific method is to set the alg field in the header of the first part of JWT to none, and then set the signature of the third part to null (i.e. no signature field is added). This token can successfully pass the verification.

Key obfuscation attack

The two most commonly used algorithms for JWT are HMAC and RSA. HMAC (symmetric encryption algorithm) signs and authenticates the token with the same key. RSA (asymmetric encryption algorithm) requires two keys. First, the JWT is encrypted with the private key, and then the corresponding public key is used to decrypt and verify. If the public key is leaked (many people think the public key can be distributed), the algorithm rs256 is modified to hs256, that is, asymmetric encryption is downgraded to symmetric encryption. Then use the leaked public key to sign the token. After receiving it, the back end will use the public key to verify the token according to the algorithm specified in the header, so that the authentication passes.

Key brute force cracking

If JWT uses a symmetric encryption algorithm (such as hs256), this means that the key signing the token is also used to verify it. Since signature verification is a self-contained process, you can test the valid key of the token itself without sending it back to the application for verification. If the key setting is too simple, such as common words, birthday year, etc., combined with the known leaked password list, the key will be cracked quickly, so any token can be forged.

Kid specified attack

Kid is the key ID, which exists in the JWT header. It is an optional field used to specify the key of the encryption algorithm. If a new kid field is injected into the header and the key of hs256 algorithm is specified as 123456, a new token is generated. The server will use the specified key 123456 to verify the token.

How to avoid the defects of JWT

Among the problems listed above, except for key brute force cracking, the rest are defects caused by JWT standard design. If you choose to use the JWT standard, please find a reliable implementation library and conduct security testing. Please avoid using symmetric encryption algorithm and correctly configure security items, such as opening the verification JWT header, prohibiting alg from being set to none, prohibiting key degradation and other security measures. But the best way to avoid it is to use paseto instead of JWT, a new standard instead of JWT.

“Benefits” of session management with JWT

First, as mentioned earlier, the JWT standard is not designed for session management, nor is the paseto standard (a replacement for the JWT standard). Nowadays, most of them use JWT for session management, which is actually the client side session mode. As mentioned earlier, the client side session mode stores session data to the client. In order to prevent data tampering or disclosure, the data stored on the client is generally signed or encrypted. Many people use the JWT implementation library to put the session data in the payload area, and then generate a token and send it to the client. If the client is a web browser, it even places the received token in localstorage through JS. The above operations make developers feel that everything is under control, but they don’t know that there are thousands of vulnerabilities in one.

People who use JWT for session management claim the following advantages:

  1. Support distributed verification;
  2. High and low server pressure;
  3. Flexible and easy to use;
  4. Safer to prevent CSRF;
  5. Better effect on mobile devices;
  6. For users who block cookies.

The advantages claimed above are actually brought about by the client side session mode and the autonomous control token. But I want to tell you that all the above advantages are false propositions for users.

Natural support distributed verification

This feature is true, but the reality is that few people really need this feature. Because the session sharing technology is very mature, the existing software frameworks provide good support schemes.

High and low server pressure

It looks high and issued. The client side session mode has no server storage and query, which can reduce the pressure on the server. However, if it is really high concurrency, we should consider the pressure of business processing on the server rather than session storage and query, because this is a drop in the bucket.

Flexible and easy to use

This is a complete error. The custom use of JWT for session management requires more code configuration. Why is it flexible and easy to use?

Safer to prevent CSRF

The JWT standard introduced earlier has explained that there are many design problems in JWT, not to mention the risk of information disclosure caused by client side session mode. For CSRF prevention, unless you put the token in an area other than cookies, such as localstorage, use js to operate. However, this will bring greater risks.

Better on mobile devices

Long ago, some mobile browsers did not support cookies, but this is a thing of the past. Now, whenever it is a reliable HTTP library, the mobile development framework supports cookies, so this is not a problem at all.

For users who block cookies

Indeed, some users will block the use of cookies in order to avoid being tracked. But establishing a session requires login to verify identity information. Therefore, users who choose to block the use of cookies understand why I can’t log in. For users who really want to avoid tracking, it will not only block cookies, but also block all client storage. In this way, in the client side session mode, there is nowhere to store the session information.

If you prefer the client side session mode and really think that the client side session mode can meet your needs, you only need to use the client side session mode supported by the server-side framework instead of JWT.

The right way to HTTP session management

For a secure session, HTTPS is first required to ensure the security of the transmission channel. Then use the implementation of server side session mode, such as the cookie in the web browser to store the random identifier, that is, session ID, which is paired with the session data stored on the server. If you need to maintain a longer session, you can add a long-term remember me ID instead of arbitrarily extending the validity of the session ID.

A friend said that JWT session management can avoid the disadvantages of client side session mode through expansion. If the session is revoked, the server can join the blacklist mechanism, or the server can record the issued token and set the validity period, and then compare each request. So the question is, is this still the client side session mode?


A friend said that JWT implemented single sign on very simply. When I asked, I was speechless. Originally, it means that multiple systems are configured with the same key for token authentication, which can realize seamless authentication between systems. Yes, this is actually the advantage of client side session mode, which can achieve the effect of “single sign on” in specific scenarios. But in reality, it is impossible to achieve in most scenarios, because first, the software systems developed by different companies need to use JWT for session management, and then trust each other to share the same key (which is extremely unsafe). At present, the mainstream protocol to solve single sign on is oidc or oauth2, and SAML or CAS is older.

A friend asked, since JWT is not designed for session management, what should JWT be used for? JWT is suitable for one-time tokens, that is, short validity and one-time use. For example, it is used to retrieve the short one-time link in the email, or download the file.


[1] [EB/OL].
[2] paseto [EB/OL].
[3] [EB/OL].
[4] [EB/OL].
[5] [EB/OL].