🚀 The Simple Version
The internet forgets you between requests — every request to a server is like meeting a stranger with amnesia. Login systems exist to hand you a "wristband" (a token or session ID) that proves "I already checked this person's ID once, let them in without asking again."
Step by Step
- You submit your email + password
- The server checks it against a hashed password in the database (never stored in plain text — that's a huge red flag if you ever see it)
- If it matches, the server creates a token (a signed piece of text) and sends it back
- Your browser stores that token and attaches it to every future request, usually in a header
- The server checks the token's signature on each request — if it's valid and not expired, you're "logged in"
What's Actually Inside a JWT
A JWT (JSON Web Token) is just three chunks of text separated by dots — a header, a payload (like your user ID), and a signature. The signature is what stops anyone from tampering with it: change even one character of the payload and the signature no longer matches, so the server rejects it.
Why Passwords Are Hashed, Not Encrypted
Encryption can be reversed with the right key. Hashing (like bcrypt, which this platform's own backend uses) is a one-way street — even the server can't turn a hash back into your original password. When you log in, the server hashes what you typed and compares hashes, never the raw password.
The Practical Takeaway
If you're building your own auth for a project: never store plain-text passwords, always hash them, and keep your token secret (JWT_SECRET) out of your GitHub repo. That single mistake — committing a secret key — is one of the most common beginner security slip-ups.