Do not use as JWT session

Many people now use as a JWT session management, this is a bad practice, the reasons set forth below, there are different views of the students welcome the discussion.

First explain, JWT, there are two:

Stateless JWT, token contains session data.
Stateful JWT, token only session ID, session data is stored on the server.

This article discusses a "stateless JWT", that is, the user's session token into the data.

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

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 cryptographically signed token, they are not contradictory, can be used together, or independently.

The correct comparison is " Sessions vs. the JWT" and "cookies vs. Local Storage".

JWT claiming benefits

People often say that JWT has the following benefits:

Ease of horizontal expansion
Easy to use
Encryption, more secure
Built-in functions expired
Protection against CSRF attacks
The user can prevent the cookies after work

For these so-called benefits of our analysis will be 11.

(1) easy to scale horizontally

The session data into JWT, the server does not need to save session information, then the server is no natural state, free to expand.

Looks really brings the convenience of extension, but in fact nothing advantages of server-side save session without any difficulty:

Multi-server scenario: you can save the session with a special redis server.
Multi-cluster scenarios: between multiple clusters do not need to share the session, the same user is always assigned to the same cluster can be.

This is a very mature solution, there is no need to save the session token in the client.

(2) easy to use

A small token seemingly simple, but in reality not there, you need to deal with session management, how could the cookies out of the box than easier.

(3) more secure

Because JWT is encrypted, many people think it is more secure, cookies unencrypted, insecure.

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

Others believe that cookies will be blocked not read encrypted.

cookies just HTTP header information, is not responsible for security, this problem should be resolved using TLS, otherwise, even if JWT also can not guarantee the security of information.

(4) Built-expired function

This function is useless, whether it should expire controlled by the server, the client should not be handed over to control, otherwise, if the token is stolen, the server will not have any way.

(5) protection against CSRF attacks

Briefly about what is CSRF attacks.

Figuratively, you log in online banking, this time already with the conditions of the transfer to other accounts, such as transfer interface address is:

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

Before you did not quit online banking, you visited a malicious Web site, which has a piece of code:

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

So you losing money these days.

This is just a simple example, the actual situation is much more complicated than this, but in the final analysis, CSRF attack was a result of: the implicit authentication mechanism , that is, cookies are automatically sent to the server, the user can not guarantee that the request is approved.

So many people think that the use of JWT no problem, because the cookies do not.

So I ask you where to save it is to JWT's? There are two ways to save:

cookie: this will also face CSRF attacks.
Other places, such as Local Storage: this does avoid the CSRF, but more exposed serious security problems, Local Storage Local storage of this type can be read directly JS.

In fact, the correct way to protect CSRF attacks only: CSRF token.

(6) the user can prevent cookies after work

Unfortunately, the user prevents the cookies scene, usually just stop cookies, but to prevent all local storage, including Local Storage.

In this case, JWT is also unable to work.

JWT shortcomings

(1) Large Volume

If the session information is encoded into the token after, then the volume will be great, is likely to exceed the cookie size limit, it can only be saved in the JWT Local Storage, and also had safety problems.

Moreover, a large volume, the pressure on the larger network.

(2) unsafe

The above analysis of this problem too, if placed in a cookie, and that the traditional session program on the same subject, if placed elsewhere, there are other security issues.

(3) can not make a JWT is invalid

Unlike the session, the server can make it fail, while JWT until it expires to no effect.

For example, the server detects a security threat, nor the related JWT failure.

That is, when you find that the risk can not kill a session, if you want to solve this problem, you need the server can manage the session, then back to the stateful mode.

(4) session data is old

session data is stored in JWT, where there will be information about users, such as roles.

Prior to JWT expires, the user's role has changed, then the time of JWT information is old, and because they can not be updated.

summary

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

The purpose of this paper is not to say JWT bad, but would like to be used as the JWT session is the wrong place.

JWT's how you use? Welcome exchanges and discussions.

Since finishing translation:
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

Recommended reading: