Pros And Cons Of Using JWT (JSON Web Tokens)

JWT (JSON Web tokens) is a great way to implement authentication in your applications, though often it is being treated as a silver bullet for almost every backend project. While JWT provides a lot of benefits while implementing auth, it does come with a price. Anyone who is thinking to integrate JWT, needs to understand both the pros and cons of using JWT & carefully weigh them, before using them as their auth layer.

Pros of loving JWT:

• You can create and verify the tokens on the fly without a need to store them ever in the database.
• Simple implementation and faster development time.
• Can be used across services and specifically be isolated in an authorization micro-service that can create these tokens. The rest of your microservices can just have the public key to verify the signature of the tokens.
• The tokens are based on JSON, which is defacto standard now-a-days for inter-message communication among web application & services.

Taking a step back to understand the cons:

• Steep learning curve, if you need to understand them correctly avoiding the pitfalls.
• No way to log out or invalidate sessions for users. Moreover, there is no way for a user to disable their sessions across multiple devices.
• Since the tokens are generated and verified on the fly, we can't have access to the different logged-in clients which can pose problems when you need to identify the devices.
• Data leakage is plausible through a single secret key used for signing the tokens. It is much harder to lose the entire database, for example, in cases of session management when compared to JWTs. Since JWTs are created on the fly, the only thing that is protecting the creation of forged tokens is the secret key used to sign the tokens.
• JWTs need care & understanding for implementation. I'll give you a basic example of a simple coding mistake which is a pitfall for every developer starting with JWTs. If you use the none algorithm, it uses no signing key, which means creating a forged token is child's play (I'll explain this in a subsequent post on this blog). Once you have the forged token and you're using ids for users that are easier to guess (think of integer ids), or you're using frameworks such as Strapi that has user id 1 as the administrator, with a forged token, your entire account will be taken over in a matter of seconds.
• We should always take care of not blindly loading signing keys with the kid header in JWT. The key should always be first validated for correctness as compared with the algorithm specified in the header.

Conclusion:

While JWT is a great technology and provides very fast development times, it is time that we understand that it's not a silver bullet for the Auth (authentication/authorization) requirements of your application. If you need to maintain sessions, please by all means use session management. Take your time to learn JWTs before implementing them. While they look a lot simpler, a simple mistake such as using the none algorithm can be disastrous causing account takeovers, data loss, and much more. Having said that, JWTs can be super-useful if implemented correctly and when there is no requirement for session management.