Abstract

This article will try to illustrate the difference between JSON web tokens and session cookies based on the example of membership cards. Please help us to improve, extend or break this analogy by sending your feedback.

With no further ado, imagine that you hold memberships at two gyms in your city:

JSON Web Token

The first gym issues you a laminated paper card. The card features the following information:

• Your name
• The expiration date of your membership
• The official company stamp

This card represents a json web token.

Session Cookie

The second gym issues you a digital key card. There are no information printed on the card. The only information stored in the card's chip is your member id.

This card represents a session cookie.

Comparison

Authentication Mechanism

JSON Web Token

When you want to enter the gym, you present your card to the employee at the reception. The employee checks the authenticity of the card, reads the expiration date and then decides whether you are allowed to enter or not.

Session Cookie

When you want to enter the gym you scan your key card in the key card reader and the card reader system replies whether you are allowed to enter or not.

Fault tolerance

JSON Web Token

Imagine the employee at the reception gets sick. As long as another employee of the branch has been trained to verify membership cards, the branch can continue to operate. Even if all employees of one branch are sick, you can use the membership card to enter another branch.

The same applies to JSON web tokens. Each of your servers can independently issue and verify tokens as long as it knows the token secret. This can be especially useful if you deploy a distributed system.

Session Cookie

Imagine the keycard reader system stops working. Since all membership information is stored in this system, no branch can continue to operate. Hence, the keycard reader system represents a single point of failure.

The same applies to session cookies. In most implementations you would store the information in a key value database (e.g. Redis). If this database goes offline, none of your other servers can authenticate users anymore.

Scalability

JSON Web Token

The time it takes to get your membership verified depends on the number of employees working in a given branch. If it is a busy day and there is only one employee on site, it might take a while to get your card checked. Contrarily, you can keep the processing time low even for millions of branches as long as each branch is staffed by enough employees.

The same applies to JSON web tokens. Since each server can verify tokens independently, the scalability depends on the processing power of each server.

Session Cookie

The time it takes to get your membership verified depends on the latency of the key card system. If the system can only process five requests per second globally, it might take a while to get your card checked.

The same applies to session cookies. Since the user information are centralized in the session storage, the processing time depends primarily on the processing power and latency of the session storage.

Security

JSON Web Token

Imagine that you were misbehaving at one of the gym's branches and subsequently got banned. As long as the employees did not take away your membership card, you could still use the same card to enter other branches. The affected branch would have to call every other branch and inform them about your misheavior. All other branches would then have to write down your name somewhere and compare every visitor card with the list of banned guests.

The same applies to JSON web tokens. It is not possible to revoke a JSON web token. If you issue a JSON web token with a long expiration time, the user can continue to use this token even if you notice misheavior. You would have to inform every server about which users are banned.

Session Cookie

Imagine that you were misbehaving at one of the gym's branches and subsequently got banned from entering. The employee of the affected branch would then update your information in the key card system. This would effectively ban you from entering any other branch as well.

The same applies to session cookies. Since the session information are stored centrally they can be updated easily. This makes it trivial to promote, demote or ban users.

Summary

JSON web tokens and session cookies are two ways for users to authenticate themselves.

With session cookies you store the information about the user in a centralized place that you control. This makes them slightly less scalable and fault-tolerant but gives more control over the lifecycle of the saved information.

With JSON web tokens you store the information about the user in the token itself. This makes them more scalable and fault-tolerant but also makes it harder or even impossible to change or revoke the information.

There are workarounds for the shortcomings of both approaches.

For session cookies, this workaround can consist of replicating the session storage to ensure high availability and scalability.

For JSON web tokens, this workaround can consist of using short-lived tokens and implementing a token revocation mechanism.

It is noteworthy here that by implementing a token revocation mechanism the statelessness of JSON web tokens is lost.

Feedback

Please help us to improve, extend or break this analogy by sending your feedback.