🍪 Cookie-Based JWT Authentication

pial shek — Thu, 09 Apr 2026 19:17:39 +0000

A few weeks ago, I was staring at a project thinking —

“Where is the safest place for a frontend to store these tokens?” 🤔

Every tutorial said the same thing: localStorage.
But something felt… off. ⚠️

So I started digging deeper 🔍
And realized — if any malicious script runs on the page, localStorage is wide open.
One XSS attack… and your tokens are gone. 💀

That’s when I asked myself:
👉 What if the frontend never touches the tokens at all?

💡 That’s when I discovered Cookie-Based JWT Authentication

The idea is simple but powerful:
Instead of sending JWT tokens in the response body…
👉 store them inside httpOnly cookies

Now the browser handles everything automatically:
🍪 Stores the token
📤 Sends it with every request
🙈 Keeps it hidden from JavaScript

⚙️ Here’s what I built:

→ User logs in → server generates access + refresh tokens 🔐
→ Tokens go into httpOnly cookies (not the response body) 🍪
→ Every request automatically includes the token 🚀
→ Custom auth class reads from cookies instead of headers 🧠
→ Server validates JWT → no DB hit, fully stateless ⚡

💥 The moment it clicked for me:

Session auth → server remembers you 🗂️ (stateful)
JWT auth → server trusts a signed token ✍️ (stateless)
Cookie-based JWT → stateless + browser-level security 🔐✨

🤝 And here’s the part I didn’t expect…

It made life way easier for frontend developers.

Before:
😵 Store tokens manually
😵 Attach headers everywhere
😵 Handle refresh logic

After:
😎 Just call APIs

That’s it. No token management. No extra logic.
The browser does the heavy lifting. 💪

But let’s be real — no system is perfect ⚖️

⚠️ CSRF is back → need proper protection (sameSite / CSRF tokens)
🌍 Cross-domain setups can get tricky
📱 Mobile apps prefer headers over cookies
⏳ Still can't instantly invalidate a stateless token without a blacklist.

🚀 Despite all that…

This approach felt like a big upgrade in how I design authentication systems.

✔️ Secure by default
✔️ Stateless and scalable
✔️ Clean for frontend devs

And most importantly…
It helped me truly understand what’s happening under the hood 🧠

🛒 Have you ever wondered… how eCommerce sites remember your cart even without login?

pial shek — Tue, 03 Mar 2026 15:50:48 +0000

You visit a site.
Add products to cart.
Close the browser.
Come back after 3 days…

And BOOM 💥 your cart items are still there.

How?

Let’s break it down 👇

The naive answer: Session IDs
When you visit a website, the server assigns you a Session ID — a temporary identifier to track your activity. But here's the problem:
Session IDs are temporary. Close the browser, reopen it — new session, new ID. The cart is gone. That's not the experience users expect.
So how do production systems solve this?

The real solution: Persistent Guest Identity via Cookies + Server-Side Storage
Here's the architecture that actually works:
*Step 1 *— Generate a Persistent Guest ID
On your first visit, the frontend generates a UUID (e.g. crypto.randomUUID()) and stores it in a cookie with a long expiry (30–90 days). This ID persists across sessions, browser closes, and revisits.
Step 2 — Lazy Guest User Creation
When a guest adds a product to the cart, the backend receives that UUID and runs a simple check:

→ Does a guest user with this ID exist?
→ If NO → create a guest user record tied to this UUID
→ If YES → fetch that existing guest user

No login. No email. Just a UUID as the identity anchor.

Step 3 — Cart & Cart Items
Once the guest user is resolved:

→ Does this user have an active cart?
→ If NO → create a cart, add the item
→ If YES → append the new item to the existing cart
This means any number of products can be added across multiple visits — all seamlessly linked to that one UUID sitting quietly in the browser cookie.

Step 4 — Handling the Cookie Security Concerns
Storing sensitive cart data directly in cookies is risky (size limits, client-side tampering, XSS exposure). That's why we only store the UUID in the cookie — nothing else. All actual cart data lives safely on the server/database.

Step 5 — Cleanup with a Scheduled Job
Not every guest will ever check out. Over time, your database fills up with abandoned guest carts. The solution? A cron job / scheduler that runs periodically (daily or weekly) and:

→ Deletes guest users whose carts haven't been touched in X days (e.g. 30 days)
→ Cascades deletion to their cart and cart items

This keeps your database lean without manual intervention.

This small architectural decision improves:

✔️ User Experience
✔️ Conversion Rate
✔️ Abandoned Cart Recovery
✔️ Data Tracking

Sometimes the best engineering is invisible to users.

DEV Community: pial shek

🍪 Cookie-Based JWT Authentication

🛒 Have you ever wondered… how eCommerce sites remember your cart even without login?