JWT Authentication Flow

Authentication vs. Authorization

Before we go further, it's essential to understand two fundamental concepts that are often confused.

• Authentication is the process of verifying who you are. Think of it as showing your ID at a security checkpoint. In web apps, this is typically done by providing a username and password.
• Authorization is the process of checking if you have permission to access a specific resource. After your ID is verified (authentication), this is like checking if your security pass grants you access to a specific room.

To get a clear and concise explanation of this distinction, let's watch the first minute of this video.

The Traditional Approach: Session-Based Authentication

To understand why JWT is so popular, it helps to first look at the traditional method: session-based authentication. You've likely interacted with this system hundreds of times without thinking about it.

The flow works like this:

1. Login: You send your username and password to the server.
2. Session Creation: The server verifies your credentials. If they are correct, it creates a "session" and stores information about you (like your user ID) on the server itself—either in memory or in a database.
3. Cookie Issued: The server sends a unique Session ID back to your browser, which is stored in a cookie.
4. Subsequent Requests: For every future request you make to the site, the browser automatically includes the cookie with the Session ID.
5. Server Lookup: The server receives the Session ID, looks it up in its session store to find your information, and then processes the request.

The key takeaway here is that this model is stateful. The server must maintain a state (the session data) for every logged-in user.

This image provides an excellent visual comparison between session-based and the token-based flow we're about to discuss. Pay attention to the "Session-based" side for now.

The Modern Approach: Token-Based Authentication with JWT

JWT offers a stateless alternative. The server doesn't need to keep track of logged-in users. Let's see how that's possible.

The flow is similar at the beginning, but diverges in a crucial way:

1. Login: You send your username and password to the server.
2. Token Creation: The server verifies your credentials. If they are correct, it creates a JSON Web Token (JWT). This token is a self-contained JSON object that includes information about the user (e.g., their ID and role).
3. Signing: The server "signs" the token using a secret key that only it knows. This signature acts as a tamper-proof seal.
4. Token Issued: The server sends the entire signed token back to the client (your browser).
5. Client Storage: The client stores this token (for example, in memory or localStorage).
6. Subsequent Requests: For every future request to a protected API endpoint, the client includes the JWT in the Authorization header.
7. Server Verification: The server receives the token, checks the signature using its secret key, and if the signature is valid, it trusts the information inside the token. It can then authorize the request.

Notice the big difference: the server doesn't have to look up a session ID. All the information it needs is right there in the token sent by the client. It's stateless.

To see this flow in action, watch the following segment.

Deconstructing a JWT

A JWT isn't an encrypted, unreadable blob. It's a string with three distinct parts, separated by dots: xxxxx.yyyyy.zzzzz.

Header.Payload.Signature

This diagram breaks down the structure and an example flow.

Let's examine each part.

1. Header: A simple JSON object that specifies the signing algorithm (alg) and the token type (typ).

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

2. Payload: Another JSON object containing the "claims"—the actual data about the user and the token itself.

   • Registered Claims: Standard fields like iss (issuer), exp (expiration time), and sub (subject, often the user ID).
   • Public/Private Claims: Custom data you want to add, like a username or roles ("roles": ["admin"]).

   {
     "sub": "user123",
     "name": "Alex",
     "iat": 1516239022,
     "exp": 1516242622
   }
   

   Crucial Security Note: The Header and Payload are Base64Url encoded, which is a way of representing binary data in text format. It is NOT encryption. Anyone who gets ahold of your token can easily decode these two parts and read the contents. Never store sensitive information like passwords in the JWT payload.

3. Signature: This is the part that ensures security. It's created by taking the encoded Header, the encoded Payload, and a secret key (known only to the server), and hashing them with the algorithm specified in the header.

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

   When the server receives a token, it performs the exact same calculation. If the signature it generates matches the signature on the token, it proves two things:

   • The token was issued by this server (because no one else has the secret).
   • The payload hasn't been tampered with (because any change would result in a different signature).

To see this in a more interactive way, the following video segment uses the popular jwt.io website to build a token piece by piece.

Why is Statelessness Such a Big Deal?

The stateless nature of JWT is its superpower, especially for modern application architectures.

• Scalability: Imagine your application becomes very popular and you need to run it on multiple servers behind a load balancer. With sessions, you have a problem: if a user logs in on Server A, their session is stored there. If their next request goes to Server B, Server B doesn't know about their session, and they're effectively logged out. You'd need a complicated shared session store to solve this. With JWT, it doesn't matter which server gets the request. As long as all servers have the same secret key, any of them can validate the token independently.
• Microservices: Your background in CSE will make you familiar with the concept of microservice architecture. JWT is perfect for this. Your client can get a token from an authentication service and then use that same token to securely communicate with a dozen other microservices (a user service, a product service, an order service, etc.).
• Decoupling: It decouples your frontend from your backend's session management. The client is simply responsible for acquiring a token upon login and then attaching it to future requests.

This video from Web Dev Simplified gives an excellent explanation of these benefits.

The Full Flow: Access Tokens and Refresh Tokens

There's one more piece to the puzzle. If a JWT is stolen, the attacker can use it until it expires. To minimize this risk, we make the main token—the Access Token—have a very short lifespan (e.g., 15 minutes).

But you can't ask your users to log in every 15 minutes. That's a terrible user experience. The solution is the Refresh Token.

Here's the complete, production-grade flow:

1. Login: User logs in.
2. Issue Tokens: The server issues two tokens:
   • A short-lived Access Token (e.g., 15-minute expiry).
   • A long-lived Refresh Token (e.g., 7-day expiry).
3. Storage: The client stores both. The Access Token is often kept in memory. The Refresh Token is stored more securely, typically in an httpOnly cookie, which is inaccessible to JavaScript, protecting it from XSS attacks.
4. API Calls: The client uses the Access Token for all API requests.
5. Token Expiration: After 15 minutes, the Access Token expires. The next API call fails with a 401 Unauthorized error.
6. Token Refresh: The client's code catches this error. It then makes a request to a special endpoint (e.g., /api/refresh_token), sending the long-lived Refresh Token.
7. New Access Token: The server validates the Refresh Token. If it's valid, it issues a new Access Token.
8. Retry Request: The client gets the new Access Token and automatically retries the original API call that failed. The user never notices anything happened.

This pattern gives you both security (short-lived access tokens) and a good user experience (long-lived sessions).

This final video segment visualizes this refresh token flow perfectly.

Conclusion

You now have a solid theoretical understanding of modern, token-based authentication. This is a core concept for any web developer.

Key Takeaways:

• Authentication is about who you are; Authorization is about what you can do.
• Traditional session-based authentication is stateful, requiring the server to store session data for every user.
• JWT-based authentication is stateless. The token itself contains all the necessary user information, which is a major advantage for scalability and modern architectures.
• A JWT consists of a Header, a Payload (which is readable by anyone), and a Signature (which ensures the token's integrity).
• The production-standard authentication flow uses a short-lived Access Token for API requests and a long-lived Refresh Token to get new access tokens without forcing the user to log in again.

Preview of the Next Lesson:
We're ready to start building! The very first step in any authentication system is handling passwords. In the next lesson, you will learn to hash and salt user passwords securely during registration using bcrypt. You can't have a secure login system if you're storing passwords in plain text.