JWT Explained: The Modern Authentication Standard and How We Survived Before It

Welcome back to Code With Botina. If you’ve been building APIs or modern applications, you’ve almost certainly run into the great dilemma: "How do I securely know who the user making this request is?".

Today we are going to demystify one of the most used (and sometimes misunderstood) technologies in web architecture: JWT (JSON Web Tokens). We’ll see what they are, how they are used in real life, and what the dark world of authentication looked like before they existed.

---

The Past: How did we authenticate before JWT? (Stateful Sessions)

To understand why JWT is so popular, we first need to understand the problem it solved. Before, the undisputed king was Stateful Session-Based Authentication.

It worked like this:

1. You logged in with your username and password.
2. The server verified your data and created a record in its own memory (or database) saying: "Session ID abc-123 belongs to Zeus."
3. The server returned that ID (abc-123) saved in a Cookie.
4. On every future request, your browser sent that Cookie. The server had to look it up in its memory: "Let's see, who owned abc-123? Ah yes, Zeus. Let him through."

What was the problem? Scalability. If your app grew and you needed to have 5 servers (Microservices), server number 2 had no idea who you were because your session was saved in the memory of server 1! You had to implement shared databases just for sessions (like Redis), which added a lot of complexity and latency.

---

The Present: What is a JWT? (Stateless Authentication)

JWT (pronounced "jot") stands for JSON Web Token. It is an open standard that allows information to be securely transmitted between two parties as a JSON object.

The magic of JWT is that it is Stateless. The server no longer needs to save anything in its memory to know who you are. All the necessary information travels inside the token itself.

A JWT looks like a meaningless string of text, but it is actually composed of three parts separated by dots (.):

1. Header: Tells what type of token it is and what algorithm was used to sign it.
2. Payload: This is where your data goes (called claims). For example: your user ID, your role (admin or user), and when the token expires.
3. Signature: This is the most important part. The server takes the Header, the Payload, and a Secret Key that only it knows, and generates a cryptographic signature.

If a hacker tries to change their role from "user" to "admin" in the Payload, the signature will no longer match mathematically, and the server will reject the token instantly.

---

How is a JWT used in practical life?

JWTs are mainly used for API Authentication. This is the modern flow when you log into an SPA (Single Page Application) or from your phone:

1. The Login: You enter your username and password. The server verifies in the database that you are who you claim to be.
2. Token Creation: The server takes your basic data (your ID, your email, when the session expires) and signs it with its secret key, creating a JWT.
3. The Token travels to the Client: The server returns that token to you like a digital "boarding pass."
4. Client Storage: Your browser or mobile app saves that token (usually in localStorage, or ideally in an HTTPOnly Cookie for security).
5. Future Requests: On every request (e.g., viewing your profile or buying something), the client sends this token to the server, usually in the request header called Authorization: Bearer .
6. Verification (Without a Database): The server receives the token and uses its secret key to mathematically verify the signature of the JWT. It does not need to query any database to know who you are or what your role is. It knows everything it needs just by reading the payload.

---

Conclusion

JWT has saved us from the nightmare of synchronizing servers and creating massive databases just to remember who was logged in. Its "Stateless" nature makes it perfect for Microservices architectures, REST APIs, and Serverless environments.

But be careful: JWTs are encoded, not encrypted. Anyone can read the Payload of a token! NEVER put sensitive information like passwords in your token's payload.

Have you implemented JWT in your projects yet, or are you still using stateful sessions? Let me know in the comments!

---

Subscribe to Code With Botina to keep scaling your knowledge in backend development, APIs, and security.