JWT Authentication — 7 Common Mistakes Developers Make (And How to Fix Them)

ramsha — Fri, 08 May 2026 19:44:39 +0000

I've seen these mistakes in codebases over and over again. Don't be that developer.

Why JWT Gets Misused So Often

JWT (JSON Web Tokens) looks simple on the surface. You generate a token, send it to the client, verify it on the server. Easy, right?
Wrong.

Most developers copy a tutorial, get it "working," and ship it to production without realizing they've left massive security holes open. I've been there too.

Here are the 7 mistakes I see most often — and exactly how to fix them.

Mistake #1 — Storing JWT in localStorage

This is probably the most common mistake and one of the most dangerous.

// ❌ WRONG — don't do this
localStorage.setItem('token', jwt)

Why it's dangerous:
localStorage is accessible by any JavaScript on the page. If your app has even one XSS vulnerability, an attacker can steal every user's token in seconds.

The fix:
Store your JWT in an httpOnly cookie instead. JavaScript can't touch it.

// ✅ CORRECT — set it server side
res.cookie('token', jwt, {
  httpOnly: true,
  secure: true,
  sameSite: 'strict',
  maxAge: 24 * 60 * 60 * 1000 // 1 day
})

Mistake #2 — No Token Expiration

// ❌ WRONG — token lives forever
const token = jwt.sign({ userId: user._id }, process.env.JWT_SECRET)

A token with no expiry is a permanent key to your kingdom. If it gets stolen, the attacker has access forever.

The fix:
Always set an expiration. Short-lived tokens are safer.

// ✅ CORRECT
const token = jwt.sign(
  { userId: user._id },
  process.env.JWT_SECRET,
  { expiresIn: '15m' }
)

For better UX, pair short-lived access tokens with refresh tokens.

Mistake #3 — Weak or Hardcoded Secret Keys

// ❌ WRONG
const token = jwt.sign(payload, 'secret123')
const token = jwt.sign(payload, 'myappjwtsecret')

If your secret is weak or committed to GitHub, your entire auth system is broken.

The fix:
Use a long, random secret stored in environment variables only.

node -e "console.log(require('crypto').randomBytes(64).toString('hex'))"

// ✅ CORRECT
const token = jwt.sign(payload, process.env.JWT_SECRET)

Never commit your .env file to GitHub. Ever.

Mistake #4 — Not Verifying the Token Properly

// ❌ WRONG — just decoding, not verifying
const decoded = jwt.decode(token)

jwt.decode() just base64 decodes the token. It does NOT verify the signature. Anyone can forge a token and your app will accept it.

The fix:

// ✅ CORRECT
try {
  const decoded = jwt.verify(token, process.env.JWT_SECRET)
  req.user = decoded
  next()
} catch (error) {
  return res.status(401).json({ message: 'Invalid token' })
}

## Mistake #5 — Putting Sensitive Data in the Payload

javascript
// ❌ WRONG
const token = jwt.sign({
userId: user._id,
password: user.password,
creditCard: user.cardNumber
}, process.env.JWT_SECRET)


JWT payloads are base64 encoded, not encrypted. Anyone can decode and read them.

**The fix:**

javascript
// ✅ CORRECT — only what you need
const token = jwt.sign({
userId: user._id,
role: user.role
}, process.env.JWT_SECRET, { expiresIn: '15m' })


---

## Mistake #6 — No Refresh Token Strategy

Short access tokens expire fast. Most developers just make them last 30 days instead. That's the wrong solution.

**The fix:**
- Access token: 15 minutes
- Refresh token: 7-30 days, stored in httpOnly cookie

javascript
app.post('/refresh', (req, res) => {
const refreshToken = req.cookies.refreshToken
try {
const decoded = jwt.verify(refreshToken, process.env.REFRESH_SECRET)
const newAccessToken = jwt.sign(
{ userId: decoded.userId },
process.env.JWT_SECRET,
{ expiresIn: '15m' }
)
res.json({ accessToken: newAccessToken })
} catch {
res.status(401).json({ message: 'Please login again' })
}
})


---

## Mistake #7 — Not Handling Token Revocation

Once issued, JWT can't be invalidated before expiry. If a user logs out, their token still works.

**The fix:**
Maintain a token blacklist in Redis.

javascript
// On logout
app.post('/logout', async (req, res) => {
const token = req.cookies.token
await redisClient.set(blacklist_${token}, '1', { EX: 900 })
res.clearCookie('token')
res.json({ message: 'Logged out' })
})

// In auth middleware
const isBlacklisted = await redisClient.get(blacklist_${token})
if (isBlacklisted) {
return res.status(401).json({ message: 'Token revoked' })
}




---

## Quick Reference — JWT Checklist

| Practice | Status |
|----------|--------|
| Store in httpOnly cookie | ✅ Do this |
| Set expiration time | ✅ Always |
| Use strong secret in .env | ✅ Required |
| Use jwt.verify() not jwt.decode() | ✅ Always |
| Keep payload minimal | ✅ Less is more |
| Implement refresh tokens | ✅ For better UX |
| Handle token revocation | ✅ For production |

---

## Final Thought

JWT done wrong is worse than no auth at all — it gives you a false sense of security.

The good news? All of these fixes are simple once you know about them. Implement them once properly and you never have to worry again.

If you want all of this already built and production-ready, I packaged it into a MERN boilerplate — proper httpOnly cookies, refresh tokens, protected routes, clean folder structure, everything.

**🔗 Free version:** github.com/komalkhann001-sketch/mern-boilerplate

**🚀 Full production-ready version:** payhip.com/b/ZfbnM
*(One-time purchase — less than the cost of one hour of your freelance rate)*

*Found this useful? Drop a reaction and share it with a developer who needs to see this 🚀*

How I Built a MERN Boilerplate That Saves 2 Weeks of Development Time And why every freelancer should stop rebuilding the same thing over and over

ramsha — Tue, 05 May 2026 10:39:12 +0000

And why every freelancer should stop rebuilding the same thing over and over*

Every time I started a new project — whether it was for a client, a startup idea, or just practice — I found myself doing the exact same thing.

Setting up Express. Configuring MongoDB. Writing JWT auth. Building login/register. Protecting routes. Structuring folders.

Again. And again. And again.

Two weeks. Gone. Before writing a single line of actual business logic.

I got tired of it.

So I Built Something

I decided to stop wasting time and build a production-ready MERN boilerplate once — properly — so I never have to do it again.

✅ Authentication (The Annoying Part — Done Right)

User Register & Login
JWT Authentication with refresh logic
Protected Routes on both frontend and backend
Proper error handling

✅ React Dashboard

Clean, responsive layout
Ready to plug in your own features
Component structure that actually scales

✅ Backend Setup

Node.js + Express — structured properly
MongoDB integration with Mongoose
Environment variables configured
MVC folder structure

✅ Production Ready

Clean folder structure from day one
No tutorial-quality spaghetti code
Deploy-ready configuration

What This Actually Saves You

Task	Normal Time	With Boilerplate
Auth setup	3-4 days	✅ Done
JWT + Protected Routes	2 days	✅ Done
Dashboard layout	3 days	✅ Done
MongoDB connection + models	1 day	✅ Done
Folder structure + cleanup	1 day	✅ Done
Total	~2 weeks	~1 hour

Who Is This For?

A freelancer who bills by project — stop wasting billable hours on setup
A startup founder who needs an MVP fast
A student building portfolio projects and wants real-world structure
A developer who is tired of copy-pasting the same auth code

The Folder Structure

mern-boilerplate/
├── client/
│   ├── src/
│   │   ├── components/
│   │   ├── pages/
│   │   ├── context/
│   │   └── routes/
├── server/
│   ├── controllers/
│   ├── middleware/
│   ├── models/
│   └── routes/
└── .env.example

Tech Stack

Frontend: React.js, React Router, Axios, Context API
Backend: Node.js, Express.js
Database: MongoDB, Mongoose
Auth: JWT, bcrypt
Deployment: Ready for Vercel + Railway/Render

What Developers Are Saying

"Saved me an entire week on my last client project"

"Finally a boilerplate that doesn't feel like a tutorial project"

"The folder structure alone was worth it"

Get It

👉 GitHub: github.com/komalkhann001-sketch/mern-boilerplate

If you want the full production-ready version with complete setup guide and future updates, I have packaged it as a one-time purchase — less than the cost of one hour of your freelance rate.

Final Thought

Stop rebuilding the same foundation every project. Your time is worth more than that.

The best developers are not the ones who write everything from scratch — they are the ones who ship faster by being smart about what they reuse.

Build the product. Not the boilerplate.

Found this useful? Drop a reaction and share with a developer friend who needs to hear this 🚀

DEV Community: ramsha