Token revocation
A token works until it expires or its checker learns of the revoke. With a 24-hour life and no revoke path, a stolen token works for up to 24 hours. A revoke push or a 4-minute life cuts that to seconds or minutes.
See it on the board
The same traffic runs on two boards. The simulator measured both when this page was built.
| Measure | Goal | Token trusted for 24 hours | Revoke pushed to every instance |
|---|---|---|---|
| Data age | under 300 s | 1,198 s Fail | 0 ms Pass |
| p99 latency | under 80 ms | 26 ms Pass | 26 ms Pass |
| Error rate | under 0.1% | 0% Pass | 0% Pass |
| Monthly cost | 26 USD/mo | 30 USD/mo |
Key numbers
| Number | Value |
|---|---|
| Default token lifetime | 3,600 s |
| Auth check, median | 0.1 ms |
| Change bus hop, median | 0.5 ms |
Limit 1/s per account · all codes tried in 12 days
How it works
A token proves who you are, so a server does not ask the user to sign in on every request. Each API instance checks the token itself, often from a local cache, to stay fast. This creates a gap. When an operator revokes a stolen token, the instances that cached it do not know.
In the mini board each API instance checks a token once and then trusts it for 24 hours. A revoked session keeps working on the other instances for as long as the cached copy lives. The limit is 5 minutes, so a thief has far too long.
Two fixes close the gap. You can shorten the life, for example to 4 minutes. A revoked token then works for at most 4 minutes. The cost is more checks against the session store, because tokens expire sooner. Or you can push the revoke. The session store publishes each revoke on a bus, and every instance removes the token from its cache within seconds.
The best design uses both: a short life as a backup, and a push for speed. Keep the revoke list small, because a token only needs to be on the list until it would expire anyway.
A revoke is complete only when every copy has heard it.
In the levels you shorten the life or add the push and check how long a revoked token works.