Automatic token revocation versus manual expiration checks for least‑privilege auth in Quarkus

The goal is to enforce least‑privilege authentication by denying requests that present expired credentials in a Quarkus service. Two documented paths exist: enabling the OIDC revocation check (quarkus.oidc.revocation.enabled) which contacts Keycloak’s token revocation endpoint, or relying on the stateless quarkus‑jwt extension to inspect the exp claim locally and reject the token without external calls.

Constraints include the added latency and possible throttling of network round‑trips to the revocation service, versus the risk that a manual exp check may allow a short window of stale privilege if the token is cached by intermediaries or if Keycloak’s revocation list is not immediately consistent across its cluster. Developers must also consider how distributed caches or offline tokens affect the reliability of the revocation flag. Which approach provides tighter least‑privilege guarantees under high‑latency or throttled network conditions? How does enabling quarkus.oidc.revocation.enabled impact throughput and response‑time variance in a production workload? What is the acceptable stale‑privilege window when relying solely on local exp validation, and can it be bounded by application‑level token caching policies?