Your JWT-based auth means a fired employee keeps access for 15 minutes after their account is disabled. Security says that is unacceptable. What are the options?

Why the gap exists

A signed JWT is validated locally from its signature. That is the whole benefit — no network call, no shared session store, resource servers that scale independently. It is also why the token cannot be un-issued: nothing consults the issuer, so nothing learns the account was disabled.

The options, from cheapest to strongest

1. Shorten the access token lifetime. Fifteen minutes to five, or to one. Reduces the window proportionally, costs more refresh round trips, and requires no architectural change. Often sufficient — and the question to ask security is what window is actually acceptable, because "zero" and "under a minute" have very different costs.

2. Revoke the refresh token immediately. Usually already possible, and it caps total access at one access-token lifetime. Combined with option 1 this addresses most of the concern for a small fraction of the effort.

3. A revocation list or event stream. The issuer publishes revoked token or subject identifiers; resource servers subscribe and cache. Near-immediate revocation with no per-request call. The list stays small because entries can be dropped once the token would have expired anyway. This is the best cost-to-benefit option for most systems.

4. Introspection for high-value operations only. Ordinary requests validate locally; consequential actions — payments, data export, administrative changes — call the issuer. Stratified rather than uniform, so the cost lands where it is justified.

5. Full introspection on every request. Immediate revocation, and it makes the authorisation server a hard dependency of every request and adds latency everywhere. Rarely the right trade.

What I would recommend

Options 1, 2 and 3 together. Short access tokens, immediate refresh revocation, and a revocation event stream. That gives sub-minute effective revocation without making the issuer a per-request dependency.

The point worth making to security

The joiner-mover-leaver process is the larger risk. A 15-minute token window is a bounded, known exposure. Accounts that are never disabled at all, service accounts belonging to departed staff, and standing access that was granted for one project and never removed are unbounded — and they are usually where the real gap is.

What a strong answer adds

Noting that the same reasoning applies to downgrade, not only disablement: a user whose permissions are reduced keeps the old claims until the token expires. If authorisation decisions are embedded in the token rather than evaluated at the resource, that window applies to every permission change — which is an argument for keeping tokens thin and authorising at the resource.