Why don’t many people recommend you to use JWT?
If you often look at some online tutorials that take you to do the project, you will find that there are many projects that use JWT. so he in the end safe? Why so many people do not recommend you to use. This article will take you from all aspects of the understanding of JWT and his advantages and disadvantages.
What is JWT?
This is his official website JSON Web Tokens – jwt.io
This is JWT.
JWT Full name JSON Web Token
If you’re not familiar with JWTs, don’t panic! They are not that complicated!
You can think of JWT as some JSON data that you can verify is from someone you know.
Of course how to realize it we will not talk about it here, if you are interested, you can go and find out for yourself.
Let’s talk about his process:
When you log in to a website, the website generates a JWT and sends it to you.
This JWT is like a package that contains some information about your identity, such as your username, roles, permissions, etc.
You then carry this JWT with you every time you communicate with that site.
Whenever you visit a page that requires authentication, you bring this JWT to the site.
When a website receives a JWT, it verifies its signature to make sure it was issued by the website and checks the information in it to confirm your identity and permissions.
If everything is verified, you can continue to access the protected page.
Why does JWT suck?
The first thing we should be doing with JWT is to do just that:
- User registration site
- User login site
- user clicks and executes an action
- This website uses user information to create, update and delete information.
These things are often these aspects for database operations
- Logging of actions being performed by the user
- Add some data about the user to the database
- Check user permissions to see if they can perform certain actions
After that, let’s go step by step and name some of his flaws
There is no doubt about this aspect.
Let’s say we need to store a user ID as xiaou
If stored inside a cookie, our total size is only 5 bytes.
If we store the ID in a JWT. His size would increase by a factor of about 51
This definitely increases our broadband burden.
redundant signature
One of the main selling points of JWT is its cryptographic signature. Because the JWT is cryptographically signed, the receiver can verify that the JWT is valid and trustworthy.
However, almost every web framework in the last 20 years has been able to reap the benefits of cryptographic signatures when using plain old session cookies.
In fact, most web frameworks will automatically cryptographically sign (or even encrypt!) your cookies.This means that you can get the same benefits as using JWT signatures without having to use JWT itself.
In practice, in most web authentication situations, the JWT data is stored in a session cookie, which means that there are now two levels of signatures. One on the cookie itself and one on the JWT.
Token revocation issues
Since the token remains valid until it expires, there is no easy way for the server to revoke it.
Here are some use cases that could make this situation dangerous.
Logging off doesn’t really make you log off!
Imagine you logged out after sending a tweet on Twitter. You might think you’ve logged out from the server, but that’s not the case. Because the JWT is self-contained, it will remain valid until it expires. This could be 5 minutes, 30 minutes, or whatever duration is set as part of the token. So if someone has acquired the token during that time, they can continue to access it until it expires.
Possibility of obsolete data
Imagine the user is an administrator and is demoted to a regular user with lower privileges. Again, this will not take effect immediately and the user will remain an administrator until the token expires.
JWT is usually not encrypted
So anyone who can perform a man-in-the-middle attack and sniff JWT has your authentication credentials. This becomes easier because the man-in-the-middle attack only needs to be done on the connection between the server and the client
security issue
For whether JWT is secure or not. We can refer to this article
We can also see that there is a special tutorial on how to attack JWT.
Overall, JWT is suitable as a single authorization token for transferring declarative information between two entities.
However, JWT is not suitable as a storage mechanism for long-term persistent data, especially for managing user sessions. Using JWT as a session mechanism may introduce a number of serious security and implementation issues; instead, for long-term persistent data storage, it is more appropriate to use traditional session mechanisms, such as session cookies, and mature implementations built on top of them.
But wrote so much, I still want to say, if you as their own development and learning to use, do not consider the security, do not consider the performance of the case, with JWT is perfectly fine, but once used in the production environment, we need to avoid these possible problems.