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

Answer the exact question first

In RabbitMQ 4.0 the only supported way to make a revoked token unusable immediately is to reduce the authentication cache TTL. The broker keeps a local cache per node; a deleted token remains accepted until the TTL expires on each node. There is no built‑in command to push a purge across the cluster, so the revocation window is bounded by the TTL you configure.

Why the TTL matters

The token backend stores the token’s validity in a database or key‑value store. Each node validates a token once, then caches the result for the duration of rabbitmq_auth_backend_token_cache_ttl (default ~60 s). During that period the node will skip a lookup and accept the token even if it has been deleted in the backend. The cache is local, so revocation timing can differ slightly across nodes depending on when the token was last cached.

Practical guidance for shrinking the window

1. Set a low TTL. A value of 5–10 seconds is a common compromise: it keeps the revocation window short while avoiding a huge increase in lookup traffic. If your authentication store is very fast (e.g., an in‑memory KV store), you can experiment with 1–2 seconds, but be prepared for higher CPU usage.
2. Measure impact. After changing the TTL, monitor auth_cache metrics in the Management UI or via rabbitmqctl list_metrics and watch CPU and latency on the node. If the broker shows elevated load, increase the TTL slightly.
3. Use short‑lived tokens. Combine a low TTL with tokens that have a hard expiration (e.g., expires_at set to a few minutes). Even if a token is revoked, its natural expiry limits the window of abuse.
4. Granular per‑vhost permissions. Restrict the permissions that a token grants to the minimum needed for the service. This is a standard defense‑in‑depth practice and reduces the impact of a token that slips through the cache.

Cluster‑wide consistency

Because each node caches independently, a token that is revoked on the backend may still be accepted on a node that cached it earlier. The difference is usually a few milliseconds to a few seconds, depending on network latency and when the node last performed a lookup. If absolute consistency is required, consider deploying a very short TTL and ensuring that your backend lookup is fast enough to not become a bottleneck.

No immediate invalidation command

RabbitMQ currently offers no command to force a cache purge for a specific token across all nodes. The only workaround is to lower the TTL or to delete the token and wait for the TTL to expire on each node.

Next step: what you need to check

To fine‑tune the TTL, you’ll need to know how fast your authentication backend can answer a token lookup. If you’re using an external database or a networked key‑value store, measure the round‑trip latency and adjust the TTL accordingly.