Authentication was the scariest part of my backend journey. I kept hearing terms like "Session Cookies," "JWTs," "OAuth," and "Salting." Here is my attempt to de-mystify JWTs (JSON Web Tokens) based on what I implemented in my recent project.
The Old Way: Sessions
In the past, when you logged in, the server created a "session ID" and stored it in the server's memory. It gave you a cookie with that ID. Every time you clicked a page, the server looked up your ID in its memory.
Problem: If you have 1 million users, that's a lot of memory. If you have 2 servers, you need to sync that memory.
The New Way: JWT (Stateless)
JWTs are like a stamped movie ticket.
Header: "I am a JWT."
Payload: "User ID is 123. Role is Admin."
Signature: A cryptographic stamp signed by the server's secret key.
When I log in, the server creates this string and sends it to me. The server does not save anything.
When I request data later, I show my JWT. The server checks the Signature. If the math works out, it knows the token is real and hasn't been tampered with.
Where to store it?
I learned this the hard way:
LocalStorage: Easy to use, but vulnerable to XSS attacks (hackers running JS on your site can read it).
HttpOnly Cookies: Harder to set up, but safer because JavaScript cannot read them.
Top comments (0)