---
{
  "title": "JWT expiration and revocation",
  "summary": "JWT revocation addresses how a service stops accepting a token before its nominal expiration.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: JSON Web Token",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html"
    },
    {
      "title": "IETF RFC 7009: OAuth 2.0 Token Revocation",
      "url": "https://www.rfc-editor.org/rfc/rfc7009.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

JWT revocation addresses how a service stops accepting a token before its nominal expiration. Self-contained tokens do not automatically consult server-side session state. Designs may combine short-lived access tokens, controlled refresh tokens, deny lists, or introspection depending on the required response to compromise.

## A practical example

After an account takeover, a service invalidates refresh capability and applies its token revocation strategy. It also considers existing access tokens and active connections, because changing the password alone may not stop every already-issued credential.

## What to check

Document token lifetimes, refresh behavior, revocation propagation, and failure handling. Test logout, role removal, compromised signing keys, and concurrent sessions across all consuming services.

## A common pitfall

A logout button that only deletes the browser's copy does not invalidate copies held elsewhere. Token revocation requires a receiver-visible policy or expiration mechanism.

## Think it through

Why test a captured token after logout in a controlled test?

**Answer:** It reveals whether receivers actually reject the token or the interface merely removed its local copy.

## Stateless validation creates a timing decision

A fictional support application issues short-lived signed access tokens. An API can validate one locally without asking a session database on every request. That improves independence, but an account being disabled does not automatically change the already-issued token's signature or expiration. The organization must decide how quickly previously granted access should stop.

Different mechanisms make different tradeoffs. Short lifetimes bound how long an access token can remain usable under ordinary expiry checks. A deny list or a server-side status lookup can support earlier rejection but introduces shared state, availability requirements, and propagation questions. Refresh-token revocation stops new access tokens only if every refresh path enforces the change correctly.

A role removal is another useful case. If a token carries a role claim, that claim may be stale until the token is replaced or the receiver checks current policy. The application should define whether permissions come from token claims, current server state, or a carefully specified combination. Otherwise teams may disagree about what 'access removed' actually means.

## Measure the revocation window

Using designated test accounts, document the time a session is revoked and the time each service begins rejecting its credentials. Include a browser request, a background API call, and a refresh attempt where those flows exist. Do not assume they all share the same implementation.

Plan signing-key compromise separately from revoking one user's token. Removing trust in a key can affect many legitimate clients and requires coordinated recovery. A useful operational document explains the maximum accepted delay, behavior during status-service failure, and who can trigger revocation. These concrete expectations turn a logout feature into an enforceable security property.

## Related concepts

- [[jwt-security]]
- [[sessions-and-cookies]]
- [[incident-response]]