JWTs Explained: No More Auth Headaches

Authentication sucks.

Sessions, cookies, local storage, databases... there are a million moving parts.

Usually, you just install next-auth or passport.js and move on. But if you don't understand the underlying mechanism, you are opening yourself up to massive security holes.

The standard today is the JWT (JSON Web Token). It looks like a long string of gibberish: eyJhbGci....

But it's not encrypted (usually). It's just encoded. Anyone can read it.

Anatomy of a Token

A JWT has three parts, separated by dots:

1. Header (Red)

{"alg": "HS256", "typ": "JWT"} This tells the server: "I am a JWT, and I was signed using HMAC SHA-256."

2. Payload (Purple)

{"userId": "123", "role": "admin", "exp": 1735689600} This is the data. Critical Warning: Since this is just Base64 encoded, never put secrets like passwords in here. Anyone with the token can decode this part. It verifies identity, it does not hide information.

3. Signature (Blue)

This is the magic. The server takes the Header, the Payload, and a Secret Key (only known to the server) and mashes them together mathematically.

If a hacker tries to change "role": "user" to "role": "admin" in the payload, the signature won't match anymore. The server will reject it.

Statelessness: The Big Win

Why do we use these?

Scalability.

With traditional sessions, the server has to check the database for every single request to see if "SessionID 123" is logged in. That's slow.

With JWTs, the server just checks the math of the signature. It requires zero database lookups. This means you can have 10,000 users hitting your API, and your auth layer won't even blink.

Debugging Tokens

Since JWTs are just Base64 strings, you can inspect them.

We built a Token Generator & Debugger that lets you paste a token and see exactly what's inside. You can also generate random secure keys for signing your own tokens.

Common Vulnerabilities (How to Get Hacked)

If you strictly follow the "Header.Payload.Signature" model, you are mostly safe. But developers make mistakes. Here are the two most common hacks:

The "None" Algorithm Attack

The header contains "alg": "HS256". In the early days of JWTs, you could change this to "alg": "none". Some backend libraries would see this and say, "Oh, the algorithm is 'none'? Okay, I won't check the signature." Result: The hacker bypasses authentication entirely. Fix: Always whitelist the algorithms you accept on the server (e.g., strictly HS256 or RS256).

The Secret Key Brute Force

If your secret key is secret123, a hacker can brute-force it in seconds using a tool like hashcat. Once they have your key, they can sign their own tokens. Fix: Use a cryptographically strong, random string (at least 256-bit).

Access vs. Refresh Tokens: The Golden Pattern

You might ask: "If tokens are stateless, how do I log a user out?" You can't really "delete" a JWT that is on someone else's computer.

This is why we use two tokens:

1. Access Token (Short-lived): Expires in 15 minutes. Used for API calls.
2. Refresh Token (Long-lived): Expires in 7 days. Stored securely (HttpOnly cookie) and used ONLY to get new Access Tokens.

When you "logout", you delete the Refresh Token record in your database. The user's Access Token will work for 5 more minutes, but once it expires, they can't get a new one.

Security Best Practices Checklist

1. Short Expiry: Access tokens should die quickly.
2. HTTPS Only: If you send a token over HTTP, I can steal it in a coffee shop.
3. HttpOnly Cookies: Store tokens in cookies that JavaScript cannot access. This prevents XSS attacks (malicious scripts) from stealing your user's identity.
4. Validate Algorithms: Explicitly set algorithms=['HS256'] in your verification function.

Conclusion

Auth is hard, but JWTs make it portable and efficient. Understand the signature, respect the secret key, and never trust client data.

👉 Inspect Your Tokens: Token Generator & Debugger