The JWT is the most used token to authenticate a stateless application.
But it has some limits. Security limits that must be taken into account.
First of all, let’s see what really is a JWT.
The Structure of a JWT
A JWT is a JSON Web Token. It’s a signed JSON document that is used in the Web communication.
The important word here is signed.
In the encryption world there are two main categories: symmetric and asymmetric encryptions.
When encrypting a value in an asymmetric way, we transform the value into another value. But the reverse is now impossible.
And when encrypting a value in a symmetric way, we transform the value into another. But we are able to come back to the original. This is a two way road.
The JWT is a token composed in 3 parts: the first part contains the symmetric algorithm used to encrypt the JSON document, the second part is the encrypted JSON document, and the last part is a signature.
As the second part is encrypted using a symmetric algorithm, and the information of the algorithm used is present in the first part, it’s easy to reveal the original JSON document.
This leads me to the first disadvantage of a JWT.
Disadvantages
I can’t store sensitive information, as anybody can decrypt it and read the original JSON document.
What do I mean with sensitive information? I must avoid passwords, bank accounts or the like.
And what else can I store? IDs, roles, first names and last names. Information related to the user which is visible and useful for the frontend
So, what’s the advantage?
Advantages
I have a condensated JSON object into a single string.
By default, JWT uses a symmetric algorithm (HS256) to encrypt the JSON object. But I can choose an asymmetric algorithm (like RS256), with a public and private key.
I have a signature part, which certifies who created the JWT. Only the servers which has the secret key to create the signature are able to create a valid JWT. This makes the backend trust the JWT with a valid signature part.
A token is smaller than a JSON object. That’s why I can send the JWT into an HTTP header.
The JWT is a standard in the authentication industry. A lot of authentication systems use it.
I can generate and debug them with jwt.io.
I can add reserved values as the validity date, which makes a JWT invalid after a given date.
Nevertheless, as the JWT is send once to the frontend, the backend lose the control on it. If the backend needs to invalidate all the generated JWT, it’s not possible.
In fact, it’s not easy, but it’s possible. Check this article for more information.
Conclusion
| Disadvantages | Advantages |
|---|---|
| Easily decrypted | Contains a compact JSON object |
| Hard to invalidate | It’s a Standard |
| I can easily generate and debug |
There are a lot of libraries to create and read a JWT. On the backend side and on the frontend side.
It’s compact and universal.
But it is shared across the internet, so I must be careful with what I store inside.



Leave a comment