Valid until it expires, whatever happens
Once one of your tokens leaves the building, it verifies successfully until it expires, whatever happens in between.
The user logs out. Changes a phished password. Gets banned. Gets fired. There is no list of live tokens to delete from, because not keeping that list was the whole point.
Expect the moment when somebody says kill this person's access now, and the honest answer is in 24 hours.
Short tokens and a refresh path
Make the access token too short-lived to matter. That is the standard mitigation. Five to fifteen minutes.
Alongside it, keep a long-lived refresh token recorded on your side, which the client quietly exchanges for fresh access tokens. Revoking now means deleting that refresh token: the current access token lives out its few remaining minutes and then the user is out.
Notice you brought state back, and only into the refresh path, which runs once every few minutes per client instead of on every request.
Add a denylist when even minutes are too long. Keep a set of revoked token identifiers in memory and check it on each request. Entries expire when the token would have anyway, so the set stays small: only tokens revoked early, only until their natural expiry.
This puts a lookup back on your hot path. Some teams apply it only to high-value routes and live with the window elsewhere. A lighter version is a version number per user compared against a cached counter, so revoke everything for this person becomes one increment.
Pick the window deliberately, because that is what interviewers probe. Your access token lifetime is exactly the maximum time a stolen or stale credential keeps working. Set it by asking how long you can tolerate that, not by copying a tutorial.
Worked example
Marcus, the ops lead at a fintech, offboards a contractor on a Tuesday: Google Workspace disabled, VPN certificate revoked, done by 9:40 am. At 2 pm the contractor's automation is still writing to the internal API, because its JWTs carry a 24-hour exp and nothing else gets checked. Nothing malicious happened, the scripts were just still running, but the incident review question is uncomfortable: what if the departure had been hostile? The changes that came out of it: access tokens cut to 10 minutes, refresh tokens stored in the main database keyed by user, and the offboarding script now deletes refresh tokens in the same run that disables SSO. The exposure window drops from 24 hours to 10 minutes, and the cost, one extra refresh call per client per 10 minutes, never shows up on a latency graph.