Securing your web application with JWT tokens

Let’s say you walk into a hotel. At the reception, you check in and show your ID. Then you get your room’s key card. You do not have to go back to the reception every time you want to open your room door throughout the duration of your stay. Only you have to use your key card!

JWT tokens are exactly that! The card verifies your identity. It is your electronic key card, proof of who you’re without needing to check in again. Without something like this, the server would have to ask “who are you?” each time a user clicks a button or loads a page, which would be slow and challenging to handle.

What is a JWT ?

The shortened term for JSON Web Token is JWT. It is simply a brief, self-contained text string that contains user data. No one can tamper with it because it is signed and verified.
The JWT token is actually three parts, divided by dots, and is encoded instead of encrypted;

• HEADER
• PAYLOAD
• SIGNATURE

Breaking down the three parts

1. HEADER : describe the type of token and the algorithm that was used to encode it.
2. PAYLOAD : real user information. The claims section is what is known as it. The payload is essentially encoded rather than encrypted. Anyone can read and decode it. Sensitive data, including passwords, should never be included in the payload.
3. SIGNATURE: using a private key from an asymmetric key pair (RS256, ES256), where any service having the public key can validate the token, or a secret key that is only known by the server (HMAC/HS256). If someone tries to modify the payload (such as by changing their role from “user” to “admin”), the signature will no longer match. When the server sees it, it will reject the token.

How JWT Authentication actually works ?

1. The user enters their login and password to access the system
2. Server verifies credentials
3. The server generates a JWT and sends it.
4. User’s browser stores the JWT
5. The user sends the JWT for each future request
6. Server verifies the JWT and responds

The server has no session storage. Every request doesn’t require a database lookup. The proof is the token.

Authentication and Authorization

Authentication is the process of verifying identity. Your username and password, a fingerprint, a one-time code. You prove you’re who you claim to be.

Get Himasha Wijewickrama’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

After authentication, authorization has happen. Even after identifying you, the system decides what you can do. When a JWT is issued, authentication takes place during login.

When to use JWT ?

• JWT works well when creating a REST API that is used by a mobile application or a frontend framework like React or Vue. Carrying the token on the client side makes sense because mobile apps lack a reliable way to store server side sessions.
• When you have multiple backend services that must all verify the caller’s identity, JWT helps. Every service can use the shared secret to independently verify the token rather than contacting a central database to determine “is this user valid?” JWT is often used in microservices for just this reason.
• JWT avoids the need to keep a session database. All the information the server requires is contained in the token itself. Just confirm and reply. No shared memory or lookup!
• A JWT can transfer seamlessly between domains if you have several apps or domains and you want a user to log in once and move freely between them. Sessions are unable to manage that with ease.

When not to use JWT ?

• JWT is probably more than you need if the caller is an automated script or another server rather than a human user. There are no user-clicking buttons, no session to maintain, and no login flow. A straightforward API key is more useful and cleaner in such a scenario.
• JWT will give you issues if you are developing something that requires you to immediate revoke access. There is no simple way to invalidate the token as soon as a user logs out or is banned because it is only valid till it expires. Building additional tools, such as a token blocklist, would be necessary, which starts to invalidate the initial goal of using JWT.
• An API key is a better choice if your use case is straightforward and long-lasting, such as granting a developer access to your API for months without requiring re-authentication. Short-lived tokens and refresh flows are the core of JWT. It adds unnecessary complexity to force that pattern onto a simple integration.

Conclusion

JWT tokens are just a smart agreement between your client side and the server. They are not magical! Get a signed key card, log in once, and keep it with you. On the server side, nobody really has to remember you. :)
However, they have limitations just like any other. Use them while developing distributed systems, mobile apps, and APIs. When you need full control, reach for sessions. When machines are communicating with one another, reach for the API keys.
The idea was never to apply JWT everywhere, but rather to recognize its purpose. So that you could make the best decision for your situation.

Happy Coding! 😃🎉