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.
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.
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.
Header 🔖
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.
If you want, you can try and have fun with building JWTs at jwt.io.
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.
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
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.
