Can Vert.x JWT handler attempt token refresh before returning 401 for expired credentials?

Goal

Determine whether the Vert.x JWT authentication handler can be set up to attempt a token refresh or rotation before rejecting an expired access token, while still enforcing least‑privilege authorization on each protected route.

Constraints and uncertainty

Vert.x separates authentication from authorization, and the built‑in JWT validator rejects tokens whose exp claim has passed. The framework does not provide a native refresh‑token flow, so any grace period or rotation must be implemented manually. Clock skew, key rotation, and differing session, JWT, and OAuth lifetimes add further ambiguity.

Specific questions:

1. Can the JWT handler be configured to return a 401 only after a failed refresh attempt?
2. What is the recommended pattern for preserving least‑privilege checks during a refresh window?
3. How should key‑rollover overlap be coordinated to avoid false expiry rejections?