JWT Authentication

Why we need Authentication in our application

Imagine you walk into a private club. The bouncer doesn't just let you in because you look nice you need a membership card. In the digital world, Authentication is that process it’s how a server verifies that you are who you say you are.

Without it, anyone could edit your profile, delete your data, or post on your behalf. We need a way to prove identity once, then stay "logged in" without having to type a password for every single button click.

What is a JWT (JSON Web Token)?

In the old days, servers kept a list of every logged-in user in their memory (Sessions). It was like a bouncer memorizing every face in the club. But if the club gets too big, the bouncer’s head explodes.

JWT (JSON Web Token) is the modern, "stateless" solution. Instead of the server remembering you, it gives you a digital, tamper-proof ID card. You carry it, you show it, and the server just checks if the signature is valid. It doesn't need to check a database every single time.

The Secret Handshake: Why Your App Needs Authentication

Imagine you walk into a private club. The bouncer doesn't just let you in because you look nice; you need a membership card. In the digital world, Authentication is that process—it’s how a server verifies that you are who you say you are.

Without it, anyone could edit your profile, delete your data, or post on your behalf. We need a way to prove identity once, then stay "logged in" without having to type a password for every single button click.

---

What is a JWT (JSON Web Token)?

In the old days, servers kept a list of every logged-in user in their memory (Sessions). It was like a bouncer memorizing every face in the club. But if the club gets too big, the bouncer’s head explodes.

JWT (JSON Web Token) is the modern, "stateless" solution. Instead of the server remembering you, it gives you a digital, tamper-proof ID card. You carry it, you show it, and the server just checks if the signature is valid. It doesn't need to check a database every single time.

The Anatomy of a JWT

A JWT looks like a long, messy string of gibberish separated by two dots. It has three distinct parts:

1. Header: Tells the server what kind of token this is and which hashing algorithm was used (usually HS256).

2. Payload: The important part of the token. It contains user data like userId or username.
   Don’t put passwords or secrets here; anyone can decode this part easily!

3. Signature: This is the secret sauce. The server takes the Header and Payload, mixes them with a Secret Key known only to the server, and creates a unique hash. If even one character in the payload changes, the signature won't match anymore.

JWT Lifecycle

The Login Flow

When a user logs in, the magic happens in these steps:

1. Request: The user sends their username and password to the server.

2. Validation: The server checks the database. If the credentials are correct, the server creates a JWT using its private SECRET_KEY.

3. Delivery: The server sends that JWT back to the browser.

Sending the Token

Once the browser has the token, it doesn't just sit there.

1. For every "protected" request (like fetching your private messages), the browser sends the token in the Authorization Header: Authorization: Bearer <your_token_here>

2. Protecting Routes On the Node.js side, we use Middleware to protect specific routes.

3. The server intercepts the request.

4. It grabs the token from the header.

5. It verifies the signature using the SECRET_KEY.

6. If valid: The request proceeds to the controller.

7. If invalid: The server sends back a "401 Unauthorized" error.

Things as dev we should know

• JWTs are not "Encrypted": They are Encoded. Anyone can paste a JWT into jwt.io and read your payload. Never put sensitive data like credit card numbers or passwords inside a JWT.

• The "Stateless" Trap: Since the server doesn't "track" the token, you can't easily revoke it. If a user’s token is stolen, they are logged in until it expires. This is why Expiration Times (exp) are mandatory.

• Local Storage vs. Cookies: Storing tokens in localStorage makes you vulnerable to XSS (Cross-Site Scripting). For better security, many pros use HttpOnly Cookies, which JavaScript cannot touch.

• Secret Key Safety: If your SECRET_KEY leaks, your entire security system is compromised. Use environment variables and never, ever hardcode it into your GitHub repo.