RabbitMQ 4.0 token authentication: revoked tokens stay valid until cache TTL expires

Token revocation window in RabbitMQ 4.0

We are migrating service authentication to the built-in token backend (rabbitmq_auth_backend_token) introduced in RabbitMQ 4.0.0, with per-token expiration timestamps and least-privilege configure/write/read permissions scoped per user and virtual host.

The design goal is straightforward: when a token is compromised or a credential is rotated, deleting the token entry should cut off access immediately. From the documented behavior, however, the broker caches token validation results, so a deleted or revoked token may remain usable until the token cache TTL (defaulting to roughly 60 seconds) elapses. There appears to be no built-in mechanism to force immediate invalidation.

For short-lived automation credentials this window matters, and I want to design around it deliberately rather than discover it during an incident.

Open questions

• Is lowering the token cache TTL the only supported way to shrink the revocation window, and what is the practical performance cost of setting it very low (e.g., 1–5 seconds) on a busy cluster?
• Does the token cache behave consistently across cluster nodes, or can revocation timing differ per node?
• Is combining short token expiration with narrow per-vhost permissions an accepted mitigation, or is there a documented pattern for immediate revocation I am missing?