The Anubhav portal was launched in March 2015 at the behest of the Hon'ble Prime Minister for retiring government officials to leave a record of their experiences while in Govt service .
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:
"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:
"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
Join MindStick Community
You need to log in or register to vote on answers or questions.
We use cookies to ensure you have the best browsing experience on our website. By using our site, you
acknowledge that you have read and understood our
Cookie Policy &
Privacy Policy.
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:
This limits how long a stolen or invalid token can be used.
2. Implement Refresh Tokens (Best Practice)
3. Maintain a Token Blacklist / Blocklist
jticlaim or unique ID).4. Use a Token Version / Timestamp in Claims
Include a
token_versionorlast_password_changein the JWT:5. Force Logout or Invalidation via Server Flag
Store a
isLoggedOutflag or alastLogoutTimeon the server.On every request:
iat(issued at) claim in the JWT.iat < lastLogoutTime, consider it invalid.6. Client-Side Logout
When the user logs out:
localStorage,sessionStorage, or cookies.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:
exp+ refresh token rotation or blacklist check.Summary