Pros and Cons of JWTs (JSON Web Tokens)

Pros and Cons of JWTs (JSON Web Tokens)

Benefits & Drawbacks of JWTs and when & when not to use them.

ยท

6 min read

Hello Hashnoders. ๐Ÿ‘‹
JWTs are widely used throughout the internet and in this article I am going to take a deeper look at them. I hope by the end of this article, you have a better understanding of what JWTs are, how they work, their benefits and drawbacks, and finally when and when not to use them.

123.jpg

What are JWTs ?

A JSON Web Token is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. The information can be signed digitally and verified on the other end. When tokens are signed using a key, the signature also ensures that only the party holding the key can decoded the token and read the information.

While they can be used to transmit any piece of information, they are most commonly used to validate users for Authentication by serving as Authorization Bearer tokens.

5834555ede7a912e00000942.png

Structure of a JWT ๐Ÿ—๏ธ

A JWT consists of three parts separated by dots.

  • Header
  • Payload
  • Signature

A typical JWT looks like

xxxxx.yyyyyyyy.zzzz

Let's break down the different parts.

The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.

Example:

{
  "alg": "HS256",
  "typ": "JWT"
}

Then, this JSON is Base64Url encoded to form the first part of the JWT.

Payload ๐Ÿงณ

The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data.

This is the actual data that is being transmitted.

Example:

{
   "username" : "spiderman",
   "name" : "Peter Parker",
   "uuid" : "26da8586-fb7b-4126-a082-54e708152e50"
}

The payload is then Base64Url encoded to form the second part of the token.

Note : Since the data is Base64 encoded, anyone can simply decode it and read it. Hence confidential information or secrets such as password should never be stored here.

Signature ๐Ÿ”

The signature is created with the encoded header, encoded payload, a secret key and the algorithm specified.

This signature can be used to verify the integrity of the token. It is used to validate that the token is trustworthy and has not been tampered with. When you use a JWT, you must check its signature before storing and using it.

You only need to provide the secret key here. Rest is auto-generated.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret123)

This is what the JWT for the above data would look like.

Screenshot 2021-08-09 125231.png

If you want, you can try and have fun with building JWTs at jwt.io.

Pros and Cons of JWTs

Like any other technology, JWTs too have some pros and cons. Its not perfect but its not too bad either.

Short Version

Coz who reads an entire blog.

๐Ÿ‘ Pros๐Ÿ‘Ž Cons
โœ… Lesser DB Queriesโญ• More payload with every API call
โœ… Token contains all required infoโญ• Trouble managing client from backend
โœ… Easy to useโญ• Secret key compromise leads to system compromise
โœ… Use across servicesโญ• Server cannot identify clients
โœ… Fast

Long Version

Let us dive deeper into each reason to understand it better.

๐Ÿ‘ Pros

โœ… Lesser DB Queries

JWTs allow user authentication to be done without actually reading the database at all. Server can simply verify the JWT to check its authenticity and perform the required actions without needing to fetch data from the User table at all in most cases. This improves overall performance as repetitive DB queries are reduced.

โœ… Token contains all required info

All in one pack. All required info regarding the user or otherwise that is necessary can be wrapped and stored inside an encrypted token.

โœ… Easy to use

One of the main reasons why developers love using JWT is its ease of use and simplicity. Setting up your backend to use will take less than 5 minutes and your are good to go.

โœ… Use across services

Since you don't need to verify the authenticity of the token with the DB, it is suitable for micro-service architecture where different services handle different jobs. You can set up one authentication service that issues the token and use this token across multiple services as long as they can verify the integrity of the token.

โœ… Fast

Since they are very few DB queries concerned and most of the validation information is stored inside the token itself, the overall performance of the application can be boosted if JWT is used correctly.

๐Ÿ‘Ž Cons

โญ• More payload with every API call

Each API call must carry the token in its headers (generally under Authorization header as Bearer token). This in turn increases the size of the network request payload. An average JWT token takes about 50 times more memory than a session token thus bloating the size of every API request.

โญ• Trouble managing client from backend

Consider the situation where the server needs to block the user or maybe update its privileges but the user already has a JWT issued. None of these changes will be reflected on the user's side until they fetch a new JWT from the server.

โญ• Secret key compromise leads to system compromise

Since the integrity of a token can be verified only with the secret key, a lot depends on it. If this secret key is compromised for some reason then the entire mechanism fails and it leads to a system compromise. Giving this kind of power to a single developer or a variable doesn't seem appropriate.

โญ• Server cannot identify clients

Once the token is issued, the server has no idea whether the client is active or not. It is only when they ask for a refreshed token that the server actually gets to know their status. The server has no way to identify the number of active users at any point in the application. This piece of information might be important to your application so keep in mind.

When and when not to use JWTs ๐Ÿ“Š

JWTs are widely used throughout the internet and are very to set up and use. However they may not be the solution for everyone.

๐Ÿ“ˆ Use JWTs when :

  • working with a microservice architecture
  • looking for an easy solution to set up authentication service
  • want to minimize database queries

๐Ÿ“‰ Don't use JWTs when:

  • identifying clients is critical to your application
  • managing clients in realtime is a necessity
  • large API payload size is an issue
  • secret key is likely to be compromised

Conclusion

Considering everything mentioned above, ask whether JWT is really the right solution for your project requirements. And if you do end up using it, make sure to tackle to the basic secuirity concerns.

If you have anything more to add to this article, leave it down in the comments below.

ย