Native JWT expiry versus custom token revocation in Vert.x AuthProvider

Authentication goal and constraint

Enforce least-privilege access in a Vert.x application while ensuring expired credentials produce explicit HTTP 401 responses instead of silent failures.

The Vert.x AuthProvider interface permits timestamp validation inside authenticate, but the framework does not enforce a default token lifetime. Native JWT expiry keeps validation inside the token, whereas a custom revocation layer can invalidate credentials before expiry. The open decision is which approach fits a constraint requiring short-lived access tokens that must be immediately invalidatable without storing every token server-side.

It is also unclear whether authenticate returning null for an expired token should be mapped to HTTP 401 at the routing layer or inside the provider, and how refresh-token rotation affects either option.

Questions

• Should token expiry validation live in the AuthProvider implementation or in the routing handler?
• Is native JWT expiry sufficient when immediate revocation is required, or is a custom revocation store necessary?
• How should authenticate returning null for expired credentials be translated into HTTP 401 without leaking token existence?