JWT Authentication Best Explanation | Spring Boot Tutorial in HINDI

JWT Explained Step-by-Step with a Banking Example

Imagine you're using an online banking app to manage your account. Here's how JWT fits into
this process:

Step 1: Log In to the Banking App

Real Life:
You open the banking app, enter your username and password.

JWT Action:

● The server checks your credentials.

● If correct, the server creates a JWT (like a digital ID card) that contains:
○ Your user ID (e.g., 12345).
○ Your permissions (e.g., view account, transfer money).
○ Expiry time (e.g., valid for 15 minutes).
● The JWT is signed with a secret key to ensure it can’t be tampered with.
● The server sends this token back to your banking app.

Step 2: Token Storage

Real Life:
The app safely stores the token, like keeping your ATM receipt in your wallet for reference.

JWT Action:
The token is stored securely, often in:

● HttpOnly Cookies: Safe and not accessible to JavaScript (resistant to hacking).

● Local Storage or Session Storage (if security is well-managed).

Step 3: View Your Account Balance

Real Life:
You want to check your account balance.
JWT Action:

● The app sends a request to the server: "Show my balance."

● It attaches the JWT as proof of your identity (like showing your ATM receipt).
● The server:
○ Verifies the JWT’s signature (to ensure it’s genuine).
○ Checks the user ID in the payload (to identify you).
○ Ensures the token hasn’t expired.
● If everything is valid, the server responds with your account balance.

Step 4: Transfer Money

Real Life:
You decide to transfer ₹10,000 to a friend.

JWT Action:

● The app sends the transfer details (amount, recipient) to the server, along with the JWT.
● The server verifies the JWT as before and checks if you’re allowed to perform the
transaction.
● If valid, the server processes the transfer and responds with a confirmation.

Step 5: Token Expiration

Real Life:
After some time, your session at the ATM ends, and you need to re-enter your PIN.

JWT Action:

● The JWT has an expiration time (e.g., 15 minutes).

● Once expired, the server rejects requests made with the old token.
● You need to log in again to get a new JWT.

Step 6: Refreshing Tokens (Optional)

Real Life:
Imagine the ATM offers an option to extend your session without logging in again.

JWT Action:
 ● The app uses a refresh token (stored securely) to get a new JWT when the old one
expires.
● This allows you to stay logged in for longer without frequently entering your credentials.

Why JWT Works for Banking:

1. Secure Transactions:
○ The token’s signature ensures no one has tampered with your identity.
○ Tokens are valid only for a short time, minimizing risks.
2. Convenience:
○ You don’t need to log in for every action.
○ The token proves your identity for the duration of its validity.
3. Stateless Server:
○ The server doesn’t store session data for every user.
○ The token carries all necessary information, making it efficient.

Summary

● JWT is your digital ID card for online banking.

● It’s secure, lightweight, and simplifies interactions between the app and server.
● Like an ATM receipt, it proves who you are and what you’re allowed to do.
What is JWT?

JWT (JSON Web Token) is like a digital ID card for secure communication between a client
(e.g., your chat app) and a server. It helps the server confirm a user's identity without storing
session details on the server.
How JWT Works (Step-by-Step)

1. User Logs In

● User provides credentials (e.g., username/password).

● Server verifies the credentials and generates a JWT containing user details.

2. Server Sends the JWT

● The server sends the JWT to the user.

● The user stores it (e.g., in a browser's HttpOnly cookie or localStorage).

3. User Makes a Request

● For every subsequent request, the user includes the JWT (e.g., in the Authorization
header).

4. Server Verifies JWT

● The server checks:

○ The token’s signature to ensure it hasn’t been tampered with.
○ The claims (e.g., expiration time) to validate the request.

5. Access is Granted or Denied

● If the token is valid, the server processes the request.

● If invalid, access is denied (e.g., unauthorized or expired).

Why Use JWT?

1. Secure: The signature ensures the token hasn’t been altered.

2. Stateless: The server doesn’t need to store session data; all information is in the token.
3. Compact: Small size makes it easy to send in requests.
4. Interoperable: Works across different platforms and technologies.
JWT in MERN Chat Apps

JWT is extensively used in MERN chat applications to:

● Authenticate users.
● Secure real-time communication via WebSocket (e.g., using Socket.IO).

Key Best Practices

1. Set Expiration: Always set a short expiration time for JWTs.

2. Use HTTPS: Prevent token interception.
3. Avoid Sensitive Data in Payload: Payload is visible to anyone with the token.
4. Secure Storage:
○ Use HttpOnly cookies to prevent XSS attacks.
○ Avoid localStorage/sessionStorage for storing tokens.
5. Token Revocation: Use refresh tokens or token blacklisting to revoke access when
needed.

Debugging JWT

Use tools like jwt.io to:

● Decode and inspect tokens.

● Check claims (e.g., expiration time).
● Validate the signature.
JWT Basics

1. What is JWT, and why did you choose it for your chat app?

● JWT (JSON Web Token) is a compact, self-contained token used for securely sharing
information between parties.
● Why JWT in Chat App?
○ It provides stateless authentication, so the server doesn’t need to store session
data.
○ It’s easy to implement and ensures secure communication between the frontend
and backend.

2. Explain the structure of a JWT. What are its three parts, and what do they do?

A JWT has three parts separated by dots: Header.Payload.Signature.

● Header: Contains metadata like the token type (JWT) and signing algorithm (e.g.,
HS256).
● Payload: Contains user information (claims), such as user ID or roles. It’s not encrypted,
so don’t store sensitive data here.
● Signature: Ensures the token isn’t tampered with by hashing the header and payload
with a secret key.

3. Is a JWT encrypted or encoded? Explain the difference.

● JWT is encoded, not encrypted.

○ Encoded: The data is transformed to another format (Base64URL), which is
readable if decoded.
○ Encrypted: The data is made unreadable without a key, ensuring confidentiality.
● JWT’s signature ensures integrity, but the payload can be viewed.

4. What signing algorithm did you use for your JWTs? Why?

● I used HS256 (HMAC with SHA-256) because:

○ It’s simple and secure for most use cases.
○ It requires only a secret key, unlike algorithms like RS256 that require
public/private key pairs.
JWT in Your Chat App

5. How did you implement authentication using JWT in your MERN stack?

1. Login: When the user logs in, the server creates a JWT with their information and sends
it back.
2. Store Token: The token is stored in the browser (e.g., cookies).
3. Token in Requests: For each API request, the frontend sends the token to the server
for validation.
4. Protect Routes: Middleware on the backend checks the token to grant access.

6. Where do you store the JWT in your app, and why?

● HttpOnly Cookies:
○ It’s more secure as the token isn’t accessible to JavaScript, preventing XSS
(Cross-Site Scripting).
● Why Not LocalStorage?
○ Tokens in LocalStorage can be exposed to XSS attacks since they are accessible
via JavaScript.
9. Follow-up: What happens if the token is invalid or expired?

● If the token is invalid: The server responds with a 400 status code (Invalid Token).
● If the token is expired: The user is asked to log in again or use a refresh token to get a
new JWT.
10. What claims did you include in the JWT payload? Why?

● Claims I included:
○ userId: Identifies the user.
○ role: Determines user permissions.
○ exp: Token expiration time (for security).
● Why?: These are essential for verifying the user’s identity and controlling access.