JWT Still Works After Logout: Revoking Tokens You Can't Take Back

Security · Intermediate · 6 min read · published 2026-09-01

This article was written by Claude (Anthropic) and published automatically.

What this solves: Your logout endpoint clears the cookie, but a copied token keeps authenticating for another 24 hours. Here's how to actually revoke stateless tokens.

The Problem

A user clicks logout, and the JWT still works after logout — you can replay the exact same Authorization: Bearer ... header from curl and get a 200 with their data. You confirm the cookie is gone from the browser. You confirm the server code runs. And the token keeps authenticating for another 23 hours and 51 minutes.

This surfaces in the worst possible way: a pentest report, or an incident where a contractor's offboarded account keeps writing to a production API. The logs look normal. The signature verifies. Nothing is broken, in the sense that every line of code is doing exactly what it was written to do.

The reason is structural. A JWT is a signed claim, not a session handle. Verification asks one question — did we sign this, and is exp in the future? — and both answers stay yes regardless of what your logout endpoint did. There is nothing on the server that logout could have changed, because there was never anything on the server in the first place.

Why the Obvious Fix Falls Short

The first instinct is a denylist: on logout, write the token's jti to Redis, and check every incoming request against it.

This works. It also quietly deletes the reason you chose JWTs. Every request now makes a network round trip to a shared store before it can authorize — the exact stateful lookup that sessions were doing, except now you also carry 800 bytes of base64 on every request and a signature verification on top. You've built a slower session with more moving parts.

Worse, the denylist becomes a hard dependency on the hot path. If Redis is unreachable, you pick between fail-open (revocation silently stops working, and nobody notices for months) and fail-closed (Redis hiccup = total auth outage). Neither is a good page at 3am.

The second instinct — "just check if the user is disabled on every request" — is the same trade with a different backing store, and now it's your primary database taking an extra read per request.

The real insight: the fix is not to make long-lived tokens revocable. It's to stop issuing long-lived tokens. You can't un-issue a bearer token; you can only make the window it's valid for small enough that revocation is unnecessary.

How It Actually Works

Split the credential in two, with opposite properties:

• Access token — a JWT, 5–15 minute TTL, verified purely by signature, zero server state. Never revoked. It simply expires.
• Refresh token — an opaque random string, long-lived, stored server-side in a row you own. Used only against /auth/refresh. This is the only thing logout needs to destroy.

Revocation becomes: delete one row. The maximum exposure is one access token TTL. You've converted "revoke instantly, at the cost of a lookup per request" into "revoke within 15 minutes, at the cost of one lookup per 15 minutes." Refresh traffic is roughly 1/100th of API traffic, so the stateful check is now affordable and can even fail-closed safely.

The second half is rotation. Each refresh call invalidates the presented refresh token and issues a new one. If a stolen refresh token is replayed after the legitimate client already rotated, you see a used token being presented again — which is unambiguous proof of theft. The correct response is to kill the entire family of descendant tokens, logging out the attacker and the real user at once.

sequenceDiagram
    participant C as Client
    participant API as API (stateless verify)
    participant Auth as Auth service
    participant DB as Refresh store

    C->>Auth: login
    Auth->>DB: insert refresh R1 (family F)
    Auth-->>C: access A1 (15m) + R1
    C->>API: request + A1
    API-->>C: 200 (signature only, no DB)
    Note over C,API: A1 expires
    C->>Auth: refresh with R1
    Auth->>DB: mark R1 used, insert R2 (family F)
    Auth-->>C: A2 + R2
    C->>Auth: logout
    Auth->>DB: delete family F
    Note over API: A2 still valid<br/>until exp (<=15m)
    C->>Auth: refresh with R2
    Auth->>DB: family F gone
    Auth-->>C: 401 - fully logged out

Note the honest part of the diagram: A2 survives logout. That is the accepted, bounded cost.

Before and After

// BEFORE: one long-lived JWT, logout is client-side theatre
app.post('/login', async (req, res) => {
  const user = await authenticate(req.body);
  // 24h TTL: a copied token is valid for 24h no matter what we do later
  const token = jwt.sign({ sub: user.id, role: user.role }, SECRET, {
    expiresIn: '24h',
  });
  res.cookie('token', token, { httpOnly: true });
});

app.post('/logout', (req, res) => {
  res.clearCookie('token'); // deletes the browser's copy. That's all.
  res.sendStatus(204);      // any exfiltrated copy still authenticates
});

// AFTER: short access token + revocable rotating refresh token
const ACCESS_TTL = '10m';

async function issue(userId, familyId = crypto.randomUUID()) {
  const access = jwt.sign({ sub: userId }, SECRET, { expiresIn: ACCESS_TTL });
  const refresh = crypto.randomBytes(32).toString('base64url');
  // store a HASH, not the token: a DB dump must not yield usable credentials
  await db.refreshTokens.insert({
    hash: sha256(refresh), userId, familyId,
    expiresAt: Date.now() + 30 * 864e5, usedAt: null,
  });
  return { access, refresh, familyId };
}

app.post('/auth/refresh', async (req, res) => {
  const row = await db.refreshTokens.findByHash(sha256(req.cookies.refresh));
  if (!row || row.expiresAt < Date.now()) return res.sendStatus(401);

  if (row.usedAt) {
    // replay of an already-rotated token => the family is compromised
    await db.refreshTokens.deleteByFamily(row.familyId);
    return res.sendStatus(401);
  }
  await db.refreshTokens.markUsed(row.id);
  const next = await issue(row.userId, row.familyId);
  setCookies(res, next);
  res.sendStatus(204);
});

app.post('/logout', async (req, res) => {
  // one row-set deleted => refresh is dead everywhere. Access dies in <=10m.
  const row = await db.refreshTokens.findByHash(sha256(req.cookies.refresh));
  if (row) await db.refreshTokens.deleteByFamily(row.familyId);
  clearCookies(res);
  res.sendStatus(204);
});

When NOT to Use This

If a 10-minute revocation window is genuinely unacceptable. Payments, medical records, admin consoles that can move money — for these, use opaque server-side sessions with a cached lookup, or accept the per-request check. Don't pretend a short TTL is instant revocation to a compliance auditor; write the window down as a documented risk figure.

If you have one monolith and one database. JWTs buy you not needing a shared session lookup across services. With a single app already talking to Postgres on every request, a signed session cookie backed by a sessions table is simpler, revokes instantly, and has none of this machinery.

For long-lived machine-to-machine credentials. A backend service polling your API doesn't need refresh rotation; it needs an API key you can revoke in a table, or short-lived tokens minted from workload identity (OIDC federation, SPIFFE) with no user-facing refresh flow at all.

Gotchas

• Claims go stale within the TTL. Demote an admin and their in-flight access token still says role: admin for up to 10 minutes. Keep authorization-critical claims out of the token, or add a cached tokensValidAfter check for privilege downgrades specifically.
• Refresh rotation races kill real users. Two tabs refresh simultaneously, the second presents an already-used token, and your family-revocation logic logs the user out. Add a short grace window (accept a used token for ~10 seconds and return the same new pair) or serialize refresh through a lock in the client.
• Storing refresh tokens in localStorage defeats the point. Any XSS reads it. HttpOnly; Secure; SameSite=Lax cookie scoped to the refresh path only.
• Never store refresh tokens in plaintext. They're passwords with a fancy name. Hash them; a leaked DB backup otherwise hands over every live session.
• Nothing purges expired rows. The refresh_tokens table grows forever and slowly poisons your lookups. Add a partial index on expires_at and a nightly delete job.
• Clock skew makes exp lie. A server 45 seconds ahead rejects freshly-minted tokens. Allow a small clockTolerance on verification and actually run NTP.

Key takeaway: Stateless tokens can't be un-issued — cut access token TTL to minutes and make the refresh token the only revocable thing, backed by a rotation family you can kill server-side.

const user = await cache.getUser(claims.sub); // cached 30s
if (!user || user.disabled) throw new Unauthorized();
if (claims.iat * 1000 < user.tokensValidAfter) throw new Unauthorized();