DEV Community: Anish Hajare

The Security Problems Most Auth Tutorials Skip

Anish Hajare — Mon, 23 Mar 2026 08:12:07 +0000

A lot of authentication tutorials are useful.

They help you get started, explain hashing, and show how login works.

That's great.

But many of them stop right before authentication gets really interesting.

They cover:

Signup
Login
Password hashing
JWT basics

And skip things like:

User enumeration
OTP abuse
Session invalidation
Refresh token misuse
Basic abuse protection
What happens when things go wrong

While building my auth system, I realized those "extra details" are actually where most of the security thinking lives.

So this post is about the security problems many auth tutorials don't spend enough time on.

1. User Enumeration

This was one of the first issues that started bothering me.

A lot of systems return messages like:

Email not found
Password incorrect
Account not verified

That sounds helpful.

But it also gives attackers information.

If someone can test emails against your login flow and get different responses, they can start learning:

Which accounts exist
Which accounts are registered
Which ones may still be inactive

That is called user enumeration.

So in my login flow, I kept the response generic:

throw new AppError(401, "Invalid email or password");

Even if:

The email doesn't exist
The account is unverified
The password is wrong

The API responds the same way.

That small choice helps reduce information leakage.

2. Refresh Tokens Are Often Treated Too Casually

Another thing I noticed is that many tutorials introduce refresh tokens, but don't really manage them.

They often get treated like long-lived backup keys.

That creates problems.

If the same refresh token stays valid for a long time:

A stolen token may keep working
Revocation becomes harder
Session control becomes weaker

That's why I used refresh token rotation and tied refresh tokens to server-side session records.

This made it possible to:

Replace old refresh tokens
Track active sessions
Revoke specific sessions
Support logout-all behavior

It made the whole system feel much more realistic.

3. Logout Is Often Only Half Real

A lot of basic auth flows treat logout as:

Delete token from client
Clear cookie
Done

But if the backend still trusts that session, the logout is only partial.

This became especially important when I implemented:

Logout from one device
Logout from all devices

Those features forced me to think in terms of session invalidation, not just token removal.

Because real logout is not just "the frontend forgot the token."

Real logout means:

The backend no longer trusts that session.

That was a major mindset shift for me.

4. OTP Verification Has Its Own Attack Surface

Before building this project, I thought of OTP verification as a simple utility step.

Now I think of it as a tiny security system.

Because OTP flows can be abused too.

For example:

Repeated guessing
Resend spam
Using old codes
Trying many wrong codes without consequences

So I added:

OTP expiry
Attempt counting
Temporary lockout
Resend cooldowns
Fresh OTP creation on resend

That turned out to be one of the best examples of a broader lesson:

Every auth feature creates a second security problem you also need to solve.

5. Basic Abuse Protection Still Matters

I also wanted some protection against repeated request abuse on auth-sensitive routes.

So I added a simple route-level rate limiter.

This is worth describing honestly: it is a basic in-memory per-IP rate limiter, not a distributed or production-grade rate limiting system.

Still, even a simple version helps demonstrate an important idea:

Auth endpoints should not be left completely unguarded
Abuse protection should be part of the design
Simple safeguards are better than none

And in this project, that route limiter works alongside the more specific OTP protections.

So I'd describe the system like this:

It includes basic route-level per-IP rate limiting, plus OTP-specific retry limits and temporary lockout.

That feels more accurate than calling it full brute-force protection.

6. Logging Matters, But It Should Be Framed Carefully

I also added structured auth event logging.

That means auth-related actions are logged with useful metadata while sensitive values like passwords, OTPs, and tokens are excluded.

That was important to me because auth systems should give you some visibility into what happened.

At the same time, I think it's important not to oversell this.

This is best described as:

Structured auth event logging
Sensitive-field sanitization
Better visibility into auth flows

It is not a fancy enterprise audit platform, and that's okay.

For a learning project, this was a really useful layer to add.

7. Security and UX Constantly Fight Each Other

This was probably the most human lesson in the whole project.

Many auth decisions are not purely technical.

They're tradeoffs.

For example:

Generic login errors improve security, but give less feedback
OTP lockouts reduce abuse, but can frustrate legitimate users
Cooldowns limit resend spam, but can feel annoying
Short token lifetimes improve security, but may hurt convenience

I used to think security features were mostly about adding more protections.

Now I think they are often about choosing the least painful compromise.

That feels much closer to real backend design.

8. If You Don't Test Edge Cases, Auth Will Fool You

Auth features often look correct in the happy path.

The problems show up around the edges:

Multiple devices
Expired OTPs
Revoked sessions
Repeated failed attempts
Refresh token reuse
Rate-limited flows

That's why I added integration tests around the auth lifecycle instead of only testing isolated pieces.

Because auth is one of those systems where "it worked once" doesn't mean much.

📚 What This Project Taught Me

The biggest lesson was simple:

Working auth is not the same as safe auth.

And that gap is where most of the interesting engineering lives.

This project made me think more carefully about:

What trust means
How trust is renewed
How trust is revoked
How information leaks happen
How abuse shows up in small features
How architecture affects security

That changed how I look at authentication completely.

🎯 Final Thoughts

Auth tutorials are great for getting started.

But once you move past the basics, the important questions change.

It's no longer just:

How do I log a user in?

It becomes:

How do I verify ownership?
How do I control sessions?
How do I reduce information leaks?
How do I limit abuse?
How do I make logout actually mean something?

That's the part of authentication I wanted to learn through this project.

And honestly, it's the part I now find most interesting.

Have you noticed security gaps in common auth tutorials too? Drop a comment below and ask questions if you have any. I'd love to hear your take. 💬

Building Safer Email OTP Verification in Node.js: Expiry, Retries, and Lockouts

Anish Hajare — Mon, 23 Mar 2026 07:53:31 +0000

Email verification sounds simple.

And at first, it kind of is. 😄

You generate a code, send it to the user, and compare it when they type it back in.

Done.

Except... not really.

The moment I tried to make OTP verification behave more like something a real app could rely on, the hidden problems showed up fast:

What if someone brute-forces the OTP?
What if they keep requesting new codes?
What if the OTP expires?
What if email delivery fails?
How do you balance security with usability?

So in this project, I built an email verification flow with OTP expiry, failed-attempt tracking, temporary lockouts, and resend protection.

And honestly, OTP ended up being more interesting than I expected.

🤔 Why Basic OTP Flows Are Not Enough

A simple OTP flow usually looks like this:

Generate a code
Store it
Send it
Compare it later

That works for demos.

But if you stop there, you leave a lot exposed:

Users can guess the code repeatedly
They can spam resend
Expired codes may still linger
Failed delivery can create broken account states
The OTP itself becomes a small attack surface

That's why I wanted the system to do more than just "send a 6-digit code."

🧠 What My OTP Flow Does

When a user registers:

A 6-digit OTP is generated
The OTP is hashed before storage
An expiry time is set
The code is emailed to the user
The account stays unverified until the OTP is confirmed

And on top of that, the system also includes:

Attempt counting
Temporary lockout after too many failures
A resend cooldown
Fresh OTP creation on resend
Cleanup of expired records over time

🔐 Why I Hash the OTP

This was a simple but important decision.

Instead of storing the OTP in plain text, I store a hash of it.

function hashValue(value) {
  return crypto.createHash("sha256").update(value).digest("hex");
}

That means even if someone gained database access, the raw OTP would not just be sitting there in readable form.

It follows the same basic principle as password hashing:

Sensitive secrets should not be stored in plain text
The database should not become an easy source of abuse

⏳ OTP Expiry Matters

A verification code should not live forever.

So each OTP gets an expiration time.

const expiresAt = new Date(Date.now() + config.OTP_EXPIRY_MINUTES * 60 * 1000);

That helps in a few ways:

Limits how long an OTP is useful
Prevents old codes from hanging around forever
Makes the verification process more predictable

I also added a TTL index on the OTP model.

That means expired OTP records become eligible for automatic cleanup by MongoDB in the background.

That detail is worth phrasing carefully: TTL cleanup is helpful, but it is not guaranteed to happen at the exact second the OTP expires.

So the app still checks expiry directly when verifying the code.

🚫 Failed Attempts and Temporary Lockout

This was one of the most important protections in the flow.

If someone enters the wrong OTP repeatedly, the system tracks the number of failed attempts.

After enough bad attempts, the OTP is temporarily locked.

Here's the core idea:

if (otpDoc.otpHash !== hashValue(otp)) {
  otpDoc.attemptCount += 1;

  if (otpDoc.attemptCount >= config.OTP_MAX_ATTEMPTS) {
    otpDoc.lockedUntil = new Date(
      Date.now() + config.OTP_LOCKOUT_MINUTES * 60 * 1000
    );
  }

  await otpDoc.save();
  throw new AppError(400, "Invalid OTP");
}

This helps reduce OTP guessing.

Because without limits, a 6-digit code field becomes a lot easier to abuse.

🔁 Resend Protection Was Surprisingly Important

At first, resend felt like a tiny feature.

Then I thought about it a little longer and realized it needed rules too.

Without controls, users or attackers could:

Spam the resend endpoint
Flood email delivery
Reset the verification flow repeatedly
Turn a useful feature into an abuse point

So I added a resend cooldown in the OTP flow.

That means a new OTP cannot be sent immediately over and over again.

And when a new OTP is created, the previous OTP record for that user is deleted first, so only the latest code remains valid.

That also means resend creates a fresh OTP record, which naturally resets previous attempt and lock state.

🛡️ OTP Resend Protection vs Rate Limiting

This is a subtle distinction, but I think it matters.

The resend flow is protected in two different ways:

A resend cooldown specific to OTP behavior
A generic route-level rate limiter

Those are related, but they are not the same thing.

The cooldown is part of the OTP business logic.
The route limiter is a broader per-IP request limit.

I liked having both, because they protect the flow from slightly different angles.

😅 One Subtle Problem: Failed Email Delivery

Another detail I cared about was what happens if registration succeeds but the verification email fails.

That can create a frustrating state:

The user exists
The account is unverified
The OTP never arrived
The signup feels broken

So I chose to roll back registration if sending the verification email fails.

That way the system avoids leaving behind incomplete account states.

It's one of those small details that makes the flow feel much more intentional.

⚖️ Security vs Usability

This was the hardest part of OTP design.

Security says:

Expire quickly
Lock after repeated failures
Limit resends
Be strict

Usability says:

Don't punish honest mistakes too harshly
Give the user time to check email
Allow recovery when delivery is delayed
Keep the process understandable

So the real challenge was not just adding protections.

It was choosing protections that still felt reasonable for a real user.

That balance is where most of the design thinking happened.

📚 What I Learned

Building OTP verification taught me a few things:

OTP flows are small, but not simple
Every verification feature creates its own abuse risks
Hashing OTPs is worth doing
Retry limits and lockouts matter
Resend behavior needs guardrails too
Security and recovery need to be balanced together

The biggest takeaway?

Email verification is not just a checkbox feature. It's part of your security design.

And once I started thinking about it that way, the implementation got much better.

🎯 Final Thoughts

Before this project, I thought of OTP verification as a small supporting feature.

After building it, I started seeing it as a tiny system of its own with its own rules, tradeoffs, and security concerns.

That was actually one of my favorite lessons from this auth project.

If you're adding email OTP verification to your app, don't stop at "generate and compare code."

Think about:

Expiry
Retry limits
Lockouts
Resend protection
Failure handling

Because those are the parts that turn a working OTP flow into a safer one.

Have you built OTP verification before? Drop a comment below and ask questions if you have any. I'd love to hear how you handled the edge cases. 💬

How I Implemented Logout From One Device and All Devices in My Auth System

Anish Hajare — Mon, 23 Mar 2026 07:37:55 +0000

"Logout" sounds like one of the easiest features in authentication.

It's just a button, right? 😄

That's what I thought too.

But once I started building a more realistic auth system, I realized logout is only simple if you don't ask too many questions.

Questions like:

Does logout affect only this device?
What happens to other active sessions?
How do I support logout from all devices?
How do I make revoked sessions stop working right away on protected routes?

That's when I learned something important:

Real logout is not just about clearing a cookie. It's about telling the backend to stop trusting a session.

So in this project, I built both:

Logout from the current device
Logout from all devices

And it taught me a lot about session design.

🤔 Why Logout Is Harder Than It Looks

In simple auth demos, logout often means:

Delete token from local storage
Clear cookie
Redirect to login

That works on the client side.

But from the backend's point of view, that is not always enough.

If the server still trusts the session behind that token, then logout is only partially real.

That's the gap I wanted to close.

🧠 The Key Idea: Sessions Live on the Server

To make logout meaningful, I tracked sessions in the database.

Each session stores things like:

Which user it belongs to
A hashed refresh token
IP address
User agent
Whether the session is revoked
When it was revoked

That makes logout a backend-controlled action instead of just a frontend cleanup step.

🚪 Logout From the Current Device

For current-device logout, the goal is simple:

Invalidate only the session tied to the current refresh token
Leave the user's other devices alone

So the server looks up the session connected to the refresh token, marks it as revoked, and stops trusting it.

Here's the main logic:

export async function revokeCurrentSession(refreshToken) {
  const session = await sessionModel.findOne({
    refreshTokenHash: hashValue(refreshToken),
    revoked: false,
  });

  if (!session) {
    throw new AppError(400, "Invalid refresh token");
  }

  session.revoked = true;
  session.revokedAt = new Date();
  await session.save();
}

That gives logout real meaning.

It's not just "remove the cookie."
It's "this session should no longer be accepted."

🌍 Logout From All Devices

This feature was even more interesting.

A user might want to:

Sign out everywhere after suspicious activity
Clear old sessions across devices
End all active logins at once

So I added a logout-all flow.

In this implementation, the backend uses the refresh token cookie to identify the user, then revokes all active sessions for that account.

export async function revokeAllSessions(refreshToken) {
  const decoded = jwt.verify(refreshToken, config.JWT_SECRET);

  await sessionModel.updateMany(
    {
      userId: decoded.id,
      revoked: false,
    },
    { revoked: true, revokedAt: new Date() },
  );
}

That means every active session for that user becomes revoked.

🔐 What About Existing Access Tokens?

This was the part that made the design much more interesting.

Revoking refresh tokens alone is not enough.

A user may still have an access token that has not expired yet.

So I tied access tokens to a sessionId and had protected routes check whether the related session is still active.

That means protected routes do not only verify the JWT itself.

They also check:

Does the session still exist?
Does it belong to this user?
Has it been revoked?

So it's more accurate to say this:

Existing access tokens stop working on protected routes because the server checks whether their session is still active.

That's what makes session revocation effective in practice.

🧪 Testing This Was Super Important

Logout is one of those features that feels correct until you actually test it.

So I added tests for behaviors like:

Logout should revoke only one session
Logout-all should revoke every active session
Protected routes should reject access tied to revoked sessions

That last part matters a lot.

Because logout-all is only meaningful if revoked sessions are actually rejected later.

Testing helped confirm that the behavior matched the promise.

😅 What Was Challenging

The tricky part wasn't writing the endpoint itself.

It was making the whole system agree on what logout means.

That included:

Refresh token lookup
Session revocation
Protected route validation
Multi-device behavior
Making sure one-device logout doesn't affect others

This was one of those features that sounded small in product terms, but touched a lot of auth architecture underneath.

📚 What I Learned

A few things became really clear while building this:

Clearing a cookie is not the same as invalidating a session
Server-side session tracking makes logout much stronger
Logout-all is really a session revocation problem
Protected routes need session awareness if you want revoked sessions to stop working
Multi-device auth adds complexity very quickly

My biggest takeaway was this:

If your backend cannot tell whether a session is still trusted, logout is only partially real.

That idea changed the way I think about authentication.

🎯 Final Thoughts

This feature taught me that logout is not boring at all.

It's actually one of the most revealing parts of an auth system, because it forces you to answer:

Who is authenticated right now?
Which session is still trusted?
How does trust get revoked?

If you're building your own auth system, I highly recommend thinking beyond "clear the cookie."

Because once users have multiple devices, logout becomes much more than a frontend action.

Have you implemented logout-all in your own auth flow? Drop a comment below and ask questions if you have any. I'd love to talk about it. 💬

I Finally Understood JWT Auth - After Building Refresh Token Rotation From Scratch

Anish Hajare — Sun, 22 Mar 2026 14:50:59 +0000

JWT tutorials only teach the easy part. Here's what happens after.

Most auth tutorials end at "user logs in, gets a token, done." And for a while, that felt fine to me too.

Then the uncomfortable questions showed up.

What if the refresh token is stolen? How do you actually revoke a session? How do you know which device is logged in?

That's the point where I realized I needed to build something real to understand auth properly. So I built refresh token rotation backed by server-side session tracking - and it changed the way I think about authentication entirely.

😅 The Problem With "Basic" JWT Auth

A lot of beginner tutorials go like this:

✅ Create a token when the user logs in
✅ Send it to the client
✅ Verify it on protected routes

That works. Until it doesn't.

Fully stateless JWT auth makes some critical things hard:

❌ You can't easily revoke sessions
❌ You can't safely manage multiple devices
❌ A stolen refresh token stays valid until it expires (which could be days or weeks)
❌ "Logout" becomes a client-side illusion, not a server-side guarantee

🧠 The Core Concept: Controlled Token Lifecycle

Instead of treating refresh tokens like permanent keys, I made them part of a controlled session lifecycle.

Here's the high-level approach:

Token	Lifetime	Purpose
Access Token	Short-lived	Used for protected requests
Refresh Token	Longer-lived	Stored in `httpOnly` cookie, used to get a new access token

Think of it like this:

🪪 Access token = visitor pass

🔁 Refresh token = a controlled way to ask for a new pass

The access token should be disposable. The refresh token needs stricter handling.

🗺️ The Full Auth Flow

Here's the big picture of how everything fits together:

┌─────────────────────────────────────────────────────────────────┐
│                        AUTH FLOW OVERVIEW                        │
└─────────────────────────────────────────────────────────────────┘

                         ┌──────────┐
                         │  Client  │
                         └────┬─────┘
                              │ POST /login
                              ▼
                    ┌─────────────────┐
                    │   Auth Server   │
                    │  ─────────────  │
                    │  Verifies creds │
                    │  Creates session│
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
      ┌──────────────┐  ┌─────────┐  ┌───────────────┐
      │ Access Token │  │ Refresh │  │  Session Row  │
      │  (short TTL) │  │  Token  │  │  in Database  │
      └──────────────┘  │(httpOnly│  │  userId, ip,  │
                        │ cookie) │  │  userAgent,   │
                        └─────────┘  │  tokenHash    │
                                     └───────────────┘

      ┌──────────────────────────────────────────────────┐
      │              PROTECTED REQUEST                   │
      │                                                  │
      │  Client ──── Access Token ────► Protected Route  │
      │                                    │             │
      │                          Token valid? ──► ✅ OK  │
      │                          Token expired? ──► 401  │
      └──────────────────────────────────────────────────┘

      ┌──────────────────────────────────────────────────┐
      │              TOKEN REFRESH                       │
      │                                                  │
      │  Client ──── Refresh Token ──► /refresh          │
      │                                    │             │
      │                          Hash match in DB?       │
      │                          Session revoked?        │
      │                          Already used? ──► THEFT │
      │                                    │             │
      │                          ✅ Issue new tokens     │
      │                          ❌ Reject + revoke all  │
      └──────────────────────────────────────────────────┘

♻️ What Refresh Token Rotation Actually Means

When the client asks for a new access token, the server does not keep trusting the same refresh token forever.

Instead:

🔍 Verify the current refresh token's signature
🔎 Match its hash to an active, non-superseded session in the DB
🆕 Generate a new refresh token
🔄 Mark the old token as superseded (not just replace the hash)
🚫 Old refresh token stops working immediately

ROTATION CYCLE:

  Client                    Server                    Database
    │                          │                          │
    │── POST /refresh ─────►   │                          │
    │   {refreshToken}         │── findSession(hash) ──►  │
    │                          │◄── session found ───────  │
    │                          │                          │
    │                          │── generate newRefreshToken
    │                          │── mark old as superseded ►│
    │                          │── store new hash ────────►│
    │                          │                          │
    │◄── {accessToken,  ───────│                          │
    │     newRefreshToken}     │                          │
    │                          │                          │
    │  [old token is now dead] │                          │

TOKEN THEFT DETECTION:

  Attacker uses stolen (already-rotated) token
    │
    ▼
  Server looks up hash - finds it was already superseded
    │
    ▼
  ⚠️  REUSE DETECTED - revoke the ENTIRE session family
    │
    ▼
  Both the legitimate user and attacker are logged out
  The compromise is contained ✅

Here's the implementation with theft detection included:

export async function rotateRefreshToken(refreshToken) {
  // 1. Verify the incoming token is cryptographically valid
  const decoded = jwt.verify(refreshToken, config.JWT_SECRET);
  const refreshTokenHash = hashValue(refreshToken);

  // 2. Look it up in the DB - find ANY matching session (revoked or not)
  const session = await sessionModel.findOne({ refreshTokenHash });

  if (!session) {
    // Token hash not found at all - truly invalid
    throw new AppError(401, "Invalid refresh token");
  }

  // 3. If the token was already rotated (superseded), this signals THEFT
  //    Revoke the entire session to protect the legitimate user
  if (session.superseded || session.revoked) {
    await sessionModel.updateMany(
      { userId: session.userId },
      { revoked: true, revokedAt: new Date() }
    );
    throw new AppError(401, "Token reuse detected. All sessions revoked.");
  }

  // 4. Generate a brand new refresh token
  const newRefreshToken = signRefreshToken({ id: decoded.id });

  // 5. Mark the old token as superseded and store the new hash atomically
  session.superseded = true;
  session.refreshTokenHash = hashValue(newRefreshToken);
  await session.save();

  // 6. Return both new tokens to the client
  return {
    accessToken: signAccessToken({
      id: decoded.id,
      sessionId: session._id,
    }),
    refreshToken: newRefreshToken,
  };
}

⚠️ Why theft detection matters: Without it, if an attacker steals and uses a refresh token before the legitimate user does, the server happily rotates it for the attacker. The real user's next request just silently fails with "invalid token." They have no idea they were compromised. With reuse detection, the moment a superseded token is presented, the entire session gets revoked - limiting the blast radius and signaling that something is wrong.

🔐 Why I Hash the Refresh Token (and You Should Too)

This was one of those "oh yeah, of course" moments.

If refresh tokens are powerful, storing them in plain text is risky.

So instead of storing the raw token, I store a SHA-256 hash of it:

import crypto from 'crypto';

function hashValue(value) {
  return crypto
    .createHash('sha256')
    .update(value)
    .digest('hex');
}

Why this matters:

Scenario	Without Hashing	With Hashing
DB is compromised	💀 Attacker has live tokens	✅ Only useless hashes
Insider threat	💀 Employee can steal sessions	✅ Can't derive tokens from hashes
Data breach logged	💀 Tokens in log files are exploitable	✅ Hashes are worthless

🔑 SHA-256 vs bcrypt - important distinction:

You might wonder: why SHA-256 and not bcrypt like we use for passwords?

Passwords are low-entropy human-chosen strings - they need slow, salted hashing (bcrypt, Argon2) to resist brute force.

Refresh tokens are cryptographically random, high-entropy values (typically 256+ bits of CSPRNG output). Brute-forcing a random 256-bit value is computationally infeasible regardless of hash speed. SHA-256 is fast, collision-resistant, and perfectly appropriate here. Using bcrypt on a refresh token would add unnecessary latency with zero security benefit.

📱 Why Session Tracking Is the Real Upgrade

This is where the system moves from "auth demo" to "actual auth system."

Each login creates a session record in the database:

// Session schema
{
  userId:           ObjectId,   // which user
  refreshTokenHash: String,     // hashed token (NOT the raw token)
  ip:               String,     // where they logged in from
  userAgent:        String,     // which browser / device
  revoked:          Boolean,    // has this been explicitly killed?
  revokedAt:        Date,       // when was it killed?
  superseded:       Boolean,    // has this token already been rotated?
  createdAt:        Date,
}

With session tracking, the backend can now answer real questions:

✅ Which sessions are currently active?
✅ Which device or browser logged in?
✅ Has this session been revoked?
✅ Was this token already rotated (possible theft)?
✅ Should this refresh token still be trusted?

SESSION REVOCATION FLOW:

  User clicks "Log out of all devices"
              │
              ▼
    ┌─────────────────────┐
    │  Mark ALL sessions  │
    │  revoked: true      │
    │  revokedAt: now()   │
    └─────────────────────┘
              │
              ▼
    Any future refresh attempt
    finds revoked: true ──► 401

    All devices logged out
    instantly. No waiting
    for token expiry. ✅

Without this, JWT auth is like sending signed permission slips into the wild and hoping they behave.

🤔 Why Not Just Use Stateless JWT Everywhere?

Because stateless JWT is great - until you need stateful behavior.

And auth almost always needs stateful behavior:

Need	Stateless JWT	With Session Tracking
Logout one device	❌ Token lives until expiry	✅ Revoke that session
Logout all devices	❌ Impossible cleanly	✅ Revoke all sessions
Immediate invalidation	❌ Can't do it	✅ Flip `revoked: true`
Detect stolen tokens	❌ No awareness	✅ Reuse detection built-in
Track suspicious sessions	❌ No awareness	✅ IP + userAgent logged
Rotate tokens safely	❌ Risky	✅ Hash rotation + superseded flag

💡 The biggest insight:

JWT alone solves identity proof.

Session state solves lifecycle control.

In real apps, lifecycle control matters a lot.

⚖️ One honest tradeoff: Including sessionId in the access token payload (as shown in the code) is a deliberate design choice that makes the access token semi-stateful. It only adds value if you validate the session on every protected request - otherwise it's payload bloat. If you validate it server-side on every request, you're giving up some of the "stateless" benefit of JWT in exchange for tighter session control. Know the tradeoff before you make it.

😵 What Was Actually Hard to Build

The tricky part wasn't getting token generation to work. Generating tokens is easy.

The hard part was making the flow safe and consistent:

🔄 Making rotation happen without breaking the client's flow
🚫 Ensuring old refresh tokens immediately stop working
🕵️ Building reuse detection that protects users when tokens are stolen
🏗️ Designing sessions so they can be revoked individually or all at once
🧪 Keeping the logic clean enough to actually test

This is the gap between a "tutorial auth system" and something production-worthy.

📚 Key Lessons Learned

1. Refresh tokens shouldn't be treated casually

They're long-lived and powerful. Hash them. Rotate them. Track them. Detect reuse.

2. Session tracking gives your backend real control

Without it, you're flying blind. You can't revoke what you can't see.

3. Stateless auth is great - for the right problems

Short-lived access tokens? Stateless is perfect. Long-lived refresh tokens? You need server state.

4. Revocation becomes easy when sessions exist

Want to kill a session? Set revoked: true. Done. No waiting for token expiry.

5. Reuse detection is what makes rotation actually secure

Rotation without reuse detection is like changing your locks but leaving the old key working. If a rotated token is presented again, revoke everything immediately.

6. Multiple devices change everything

The moment you support multiple devices, you need per-device session tracking. There's no clean alternative.

🎯 Final Thoughts

If you're building auth in Node.js and only using JWT on its own - I really encourage you to think about refresh token rotation and session tracking.

These two ideas changed the way I think about auth systems entirely.

The biggest lesson?

JWT gives you identity. Sessions give you control. You need both.

If you've built auth before, I'd love to know how you handled refresh tokens and sessions. Drop your approach in the comments 💬

Tags: #node #security #webdev #javascript