Your Login Works. Your Authentication System Might Not.

The Login Screen Is the Easy Part

A login form is deceptively reassuring.

You enter an email. You enter a password. You click Sign in. The server accepts the credentials and redirects you to the dashboard.

From the outside, everything looks correct.

But that flow only answers one question: Can these credentials successfully create an authenticated state?

It doesn't answer what happens afterward:

• What happens when the same account opens another browser?
• What happens when the session expires?
• What happens when the user clicks “Log out of all devices”?
• What happens after a password reset?
• What happens if an old credential is stolen?
• What happens when a protected API receives a request from a session that should no longer exist?

Those are authentication questions too. And they are usually where the most critical production bugs and security holes hide.

The common mistake is treating authentication as a screen. A better engineering mental model is a complete lifecycle:

Once credentials are verified, the system must establish some representation of access. That access then needs rules:

This changes how I review an authentication implementation. Instead of asking: “Does login work?”, I ask: “Can I explain the complete lifecycle of access?”

Most authentication tests naturally follow the path of least resistance:

The second sequence is where the architecture's true assumptions become visible.

For example, suppose a user logs in successfully and receives a session. Later they click: “Log out of all devices.”

The frontend can clear its local storage. The UI can redirect to /login. The toast can announce “Logged out successfully.”

None of those things invalidate the session on the server.

If the old session token or cookie can still authenticate a protected request, the interface is lying: the UI says one thing, but the authorization layer says another.

The Server Has to Be the Authority

This is one of the most fundamental distinctions in authentication:

“Clearing client state is not the same thing as revoking server-side access.”

Imagine two browsers using the same account:

The critical part isn't that Browser B's UI changed. The critical part is that the server authoritatively rejected Browser B's old session.

This is why authentication cannot be designed entirely from the frontend. A browser can display “You are logged out”, but only the authorization layer can enforce “This session is dead.”

Every Protected Request Needs a Reason to Be Trusted

Once authentication becomes a lifecycle, another question appears: How does the application validate access after login?

A common architectural mistake is allowing the frontend to become the source of truth. For example:

That state is useful for rendering UI buttons or hiding navigation links. It should never be the final authority for protected data or operations.

The real boundary is the protected API endpoint. Conceptually:

The frontend can hide a page. The server must protect the data behind it.

Session Storage Is Part of Authentication

After verification comes issuance and storage. This is easy to overlook because the login flow makes the session feel like a single scalar value:

In reality, the system needs to define what that session represents and how it can later be evaluated. A robust session record conceptually contains:

If a credential is only valid according to its creation timestamp and expiry timestamp, but there is no meaningful revocation mechanism, then “log out everywhere” becomes impossible to enforce server-side.

Storage isn't merely an implementation detail. Storage determines what questions your authentication system can answer.

Expiry Answers “How Long?” Rotation Answers “What Replaces It?”

Every authentication system needs a lifetime. Without one, successful authentication can effectively become permanent authentication.

A simple model looks like:

After expiresAt, the credential must no longer establish access. But there is a crucial catch: A security rule that exists only in the data model isn't a security rule until the access path enforces it. If the session expired at 10:00 but an API continues accepting it at 10:15, then the expiry exists conceptually, but not operationally.

Rotation Is Different from Expiry

Expiration asks: “When should this credential stop being valid?”
Rotation asks: “Should this credential be replaced with a brand-new one?”

If refresh credentials can be reused indefinitely, the compromise window explodes. Rotating tokens ensures that if a token is intercepted, either the legitimate user or the attacker will trigger reuse detection, invalidating the entire family.

Expiry is predictable. Revocation is intentional. That is the difference.

A session might be completely healthy according to its expiry timestamp, but still needs to become invalid immediately:

• the user clicks “Log out of all devices”,
• a password is reset,
• suspicious anomaly activity is detected,
• an administrator disables access,
• or a credential is believed to be compromised.

VISUAL 03 — The Cross-Browser Revocation Test

The strongest practical test to verify any authentication implementation is simple:

This test is valuable because it crosses a system boundary. You are no longer testing whether a button works. You are testing whether state changed in the authority that controls access.

// server/auth/validate-session.ts
import { db } from "@/lib/db";
import { redis } from "@/lib/redis";

interface SessionValidationResult {
  isValid: boolean;
  user?: { id: string; email: string };
  reason?: "EXPIRED" | "REVOKED" | "NOT_FOUND" | "TAMPERED";
}

export async function validateProtectedRequest(
  sessionId: string,
  clientTokenVersion?: number
): Promise<SessionValidationResult> {
  // 1. Fast path: check Redis distributed session cache
  const cached = await redis.get(`session:${sessionId}`);
  const session = cached ? JSON.parse(cached) : await db.sessions.findById(sessionId);

  if (!session) {
    return { isValid: false, reason: "NOT_FOUND" };
  }

  // 2. Enforce natural time-to-live expiry
  if (Date.now() > new Date(session.expiresAt).getTime()) {
    return { isValid: false, reason: "EXPIRED" };
  }

  // 3. Enforce explicit administrative or user revocation
  if (session.revokedAt !== null) {
    return { isValid: false, reason: "REVOKED" };
  }

  // 4. Invalidate if a security event (e.g. password reset) bumped user version
  const user = await db.users.findById(session.userId);
  if (!user || (user.tokenVersion !== session.tokenVersion)) {
    return { isValid: false, reason: "REVOKED" };
  }

  return { isValid: true, user: { id: user.id, email: user.email } };
}

Recovery and Abuse Protection Belong in the Lifecycle Too

Password recovery is often treated as an isolated feature. From an authentication perspective, it isn't.

Suppose an account has three active sessions: laptop, phone, and office desktop. The user suspects their password was compromised and resets it.

What should happen to those three active sessions?

That is not merely a password-management question. It is an access-control question. When the user's trust relationship changes, which existing credentials should stop being trusted?

Abuse Protection: Designing for Failure

There is another failure mode that is easy to miss because it never involves a successful login: Repeated authentication attempts.

If the authentication endpoint has no abuse protection, the system can be compromised through the login path even if successful logins are handled securely. Authentication must define its behavior for failure, not only success:

• IP-level and account-level rate limiting,
• Exponential backoff and CAPTCHA thresholds,
• Audit logging and abnormal geolocation alerts.

Before approving an authentication implementation, run it through these six core questions:

The Architecture Matters Less Than the Guarantees

There are many ways to implement authentication: Redis sessions, database-backed tokens, stateless JWTs with short expiry, OAuth 2.0 PKCE, or WebAuthn passkeys.

The technology can change. The required guarantees do not.

It is easy to get lost in library debates: “Use X instead of Y.” But a stronger architecture review starts one level higher:

If the answer is yes, the system has a dependable foundation. If the answer is no, changing libraries won't fix the structural flaw.

Before declaring authentication ready for production, walk through the complete lifecycle checklist:

┌───────────┐
│  VERIFY   │ ──► Confirms credentials & identity
└─────┬─────┘
      ▼
┌───────────┐
│   ISSUE   │ ──► Mints session record & cryptotokens
└─────┬─────┘
      ▼
┌───────────┐
│   STORE   │ ──► Authoritative database/cache state
└─────┬─────┘
      ▼
┌───────────┐
│ VALIDATE  │ ──► Enforced on every single request
└─────┬─────┘
      ▼
┌────────┴────────┐
▼                 ▼
ROTATE          REVOKE ──► Immediate multi-device invalidation
│                 │
└────────┬────────┘
         ▼
      RECOVER ──► Password reset clears existing access
         │
         └────► Re-enters VERIFY