Many people now use JWT for session management, which is a bad practice. Here is why.

First of all, there are two types of JWT:

  • Stateless JWT tokens contain session data.

  • Stateful JWT tokens contain only session IDS, and session data is still stored on the server.

This article talks about “stateless JWT”, which puts the user’s session data into tokens.

JWT is not suitable as a session mechanism, it is dangerous to do so.

A lot of people like to compare “cookies vs. JWT.” This comparison is meaningless, like comparing apples and oranges. Cookies are a storage mechanism, while JWT is a cryptographically signed token, they are not opposites and can be used together or independently.

The correct comparison is “Sessions vs. JWT” and “cookies vs. Local Storage.”

Claimed advantages of JWT

JWT is commonly said to have the following benefits:

  • Easy to scale horizontally
  • Simple and easy to use
  • Encrypted, more secure
  • Built-in expiration
  • It protects against CSRF attacks
  • Cookies work even after the user blocks them

These so-called benefits will be dissected.

(1) Easy to extend horizontally

By putting session data into JWT, the server does not need to store session information, so the server is naturally stateless and can be expanded at will.

It does seem to be a convenience for scaling, but in fact it has no advantage. There is no difficulty in saving sessions on the server side:

  • Multi-server scenario: Sessions can be stored on a dedicated Redis server.
  • Multi-cluster scenario: There is no need to share a session among multiple clusters. The same user is always assigned to the same cluster.

These are mature solutions and there is no need to store sessions in client tokens.

(2) Easy to use

It seems that a small token is relatively easy, but in fact it is not. You need to handle session management yourself, how can it be easier than cookies out of the box.

(3) Safer

Because JWT is encrypted, many people think it is more secure, while cookies are not encrypted and are not secure.

In fact, cookies are just a storage mechanism, and you can use encrypted signatures.

Others believe cookies can be intercepted and read if they are not encrypted.

Cookies are only HTTP headers and are not responsible for security. This problem should be solved using TLS. Otherwise, even JWT cannot guarantee the security of information.

(4) Built-in expiration function

Whether or not the token expires should be controlled by the server, not the client. Otherwise, if the token is stolen, the server will have nothing to do.

(5) It can protect against CSRF attacks

A brief description of what a CSRF attack is.

For example, if you log in to the e-bank, you are already qualified to transfer money to other accounts. For example, the interface address of transfer is:

http://xbank.com/transfer?to=123&money=1000Copy the code

Before you quit online banking, you visit a malicious website that contains this code:

<img src=http://xbank.com/transfer?to=456789&money=1000>Copy the code

So you lose your money.

It’s a simple example, and it’s a lot more complicated than that, but at the end of the day, that’s what CSRF attacks come from: implicit authentication, where cookies are automatically sent to the server and there’s no guarantee that the request was approved by the user.

So, a lot of people think that with JWT you don’t have this problem because you don’t use cookies.

So, where do you keep JWT? There are two ways to save:

  • Cookie: This is also subject to CSRF attacks.
  • Other places, such as Local Storage: this does avoid CSRF, but exposes more serious security issues. Local Storage such as Local Storage can be read directly by JS.

In fact, the only correct way to defend against CSRF attacks is the CSRF token.

(6) Cookies work even after the user blocks them

Unfortunately, in scenarios where the user blocks cookies, it’s usually not just cookies that are blocked, but all Local Storage, including Local Storage.

In this case, JWT will not work either.

The disadvantage of JWT

(1) Large volume

If the session information is encoded and put into the token, the size of the session information will be very large and may exceed the size limit of the cookie. Then the JWT can only be saved in the Local Storage, which will cause security problems.

Moreover, the larger the volume, the greater the network pressure.

(2) Unsafe

This problem has been analyzed above, if put in cookies, it is similar to the traditional session scheme, if put in other places, there are other security issues.

(3) A JWT cannot be invalidated

Unlike sessions, which can be invalidated on the server, JWT is not invalidated until it expires.

For example, if a server detects a security threat, it cannot disable the associated JWT.

That is, you can’t kill a session when you see a risk, and if you want to fix that, you need to be able to manage sessions on the server, so you go back to stateful mode.

(4) Session data is old

Session data is stored in the JWT and contains information about the user, such as roles.

If the user’s role changes before the JWT expires, the information in the JWT is old because it cannot be updated.

summary

JWT is really not suitable for use as a session, JWT is more suitable for one-time command authentication with a very short validity period.

The purpose of this article is not to argue that JWT is bad, but that using JWT as a session is a mistake.

How do you use JWT? Welcome exchange and discussion.

Translation arrangement from: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

Recommended reading:

  • ZooKeeper is not a good registry
  • Does Redis Cluster lose data?
  • Common strategies for high concurrency
  • Interface-level fault handling policy
  • Classification and algorithm of load balancing