--- title: "How do you invalidate a JWT?" description: "How do you invalidate a JWT?" author: "Anubhav Sharma" published: 2025-06-09 updated: 2025-06-09 canonical: https://www.mindstick.com/interview/34223/how-do-you-invalidate-a-jwt category: "authentication" tags: ["authentication", "authorization", "jwt"] reading_time: 5 minutes --- # How do you invalidate a JWT? Invalidating a **JWT** (JSON Web Token) is tricky because JWTs are **stateless**—once issued, they live independently until they expire. You can’t just delete them from a server-side session store like traditional cookies. But here are several strategies to **invalidate or effectively block JWTs**: ## 1. Use Short Expiration Time (`exp`) Set a **short lifespan** (e.g., 5–15 minutes) for access tokens: ```plaintext "exp": 1717941723 ``` This limits how long a stolen or invalid token can be used. > Combine this with **refresh tokens** to allow continued user access without re-login. ## 2. Implement Refresh Tokens (Best Practice) - Issue a short-lived **access token** (JWT) and a long-lived **refresh token** (usually stored securely). - When the access token expires, the client uses the refresh token to get a new one. - You can **revoke refresh tokens** (e.g., on logout) to invalidate further access. ## 3. Maintain a Token Blacklist / Blocklist - Keep a server-side list of **revoked or invalid tokens** (e.g., by their `jti` claim or unique ID). - On each request, check whether the JWT exists in the blacklist. - Drawback: Requires a lookup, which adds statefulness. > Especially useful for logouts, account disables, or token theft. ## 4. Use a Token Version / Timestamp in Claims Include a `token_version` or `last_password_change` in the JWT: ```plaintext "tokenVersion": 3 ``` - Store the current version on the server per user. - If user resets password or logs out from all devices, increment the version. - On each request, check that the token's version matches the user's current version. ## 5. Force Logout or Invalidation via Server Flag Store a `isLoggedOut` flag or a `lastLogoutTime` on the server.\ On every request: - Parse the `iat` (issued at) claim in the JWT. - If `iat < lastLogoutTime`, consider it invalid. ## 6. Client-Side Logout When the user logs out: - Simply **delete the token** from browser `localStorage`, `sessionStorage`, or cookies. - This prevents the token from being sent in future requests. > This doesn’t prevent replay if the token was stolen—use server-side strategies too. ## You *Can’t* Directly Invalidate a JWT That’s Already Issued JWTs are self-contained. You **can’t reach into the token** and revoke it unless: - You’ve built infrastructure to **track** or **expire** them yourself. - You use **short** `exp` **+ refresh token rotation** or **blacklist check**. ### Summary | Strategy | Effective For | Requires Server State? | | --- | --- | --- | | Short expiry + refresh token | Stolen token mitigation | Partially (refresh flow) | | Token blacklist | Logout or admin revocation | Yes | | Version checking | Password reset, logout-all | Yes | | Client-side logout | Normal logouts | No | ## Answers ### Answer by Anubhav Sharma Invalidating a **JWT** (JSON Web Token) is tricky because JWTs are **stateless**—once issued, they live independently until they expire. You can’t just delete them from a server-side session store like traditional cookies. But here are several strategies to **invalidate or effectively block JWTs**: ## 1. Use Short Expiration Time (`exp`) Set a **short lifespan** (e.g., 5–15 minutes) for access tokens: ```plaintext "exp": 1717941723 ``` This limits how long a stolen or invalid token can be used. > Combine this with **refresh tokens** to allow continued user access without re-login. ## 2. Implement Refresh Tokens (Best Practice) - Issue a short-lived **access token** (JWT) and a long-lived **refresh token** (usually stored securely). - When the access token expires, the client uses the refresh token to get a new one. - You can **revoke refresh tokens** (e.g., on logout) to invalidate further access. ## 3. Maintain a Token Blacklist / Blocklist - Keep a server-side list of **revoked or invalid tokens** (e.g., by their `jti` claim or unique ID). - On each request, check whether the JWT exists in the blacklist. - Drawback: Requires a lookup, which adds statefulness. > Especially useful for logouts, account disables, or token theft. ## 4. Use a Token Version / Timestamp in Claims Include a `token_version` or `last_password_change` in the JWT: ```plaintext "tokenVersion": 3 ``` - Store the current version on the server per user. - If user resets password or logs out from all devices, increment the version. - On each request, check that the token's version matches the user's current version. ## 5. Force Logout or Invalidation via Server Flag Store a `isLoggedOut` flag or a `lastLogoutTime` on the server.\ On every request: - Parse the `iat` (issued at) claim in the JWT. - If `iat < lastLogoutTime`, consider it invalid. ## 6. Client-Side Logout When the user logs out: - Simply **delete the token** from browser `localStorage`, `sessionStorage`, or cookies. - This prevents the token from being sent in future requests. > This doesn’t prevent replay if the token was stolen—use server-side strategies too. ## You *Can’t* Directly Invalidate a JWT That’s Already Issued JWTs are self-contained. You **can’t reach into the token** and revoke it unless: - You’ve built infrastructure to **track** or **expire** them yourself. - You use **short** `exp` **+ refresh token rotation** or **blacklist check**. ### Summary | Strategy | Effective For | Requires Server State? | | --- | --- | --- | | Short expiry + refresh token | Stolen token mitigation | Partially (refresh flow) | | Token blacklist | Logout or admin revocation | Yes | | Version checking | Password reset, logout-all | Yes | | Client-side logout | Normal logouts | No | --- Original Source: https://www.mindstick.com/interview/34223/how-do-you-invalidate-a-jwt Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.