Vert.x WebSocket + JWTAuthHandler: enforcing least-privilege after a token expires mid-connection

We are integrating vertx-auth-jwt with a Vert.x 4.x HTTP server that upgrades some routes to long-lived WebSocket connections. Initial authentication works: JWTAuthHandler validates the signature and standard claims, and per-route AuthorizationHandler instances enforce PermissionBasedAuthorization so each endpoint only requires the one permission it needs.

The unresolved part is what should happen when the JWT's exp passes while the WebSocket is still open. As far as we can tell, the handler only authenticates the upgrade request, so the connection appears to stay authorized indefinitely with the permissions captured at handshake time. That conflicts with our least-privilege goal, since a user's permissions may be revoked or narrowed before the token expires.

We also see occasional premature rejections that we suspect come from clock skew between the token issuer and the Vert.x validator, but we have not confirmed whether a leeway option exists for our exact vertx-auth-jwt version.

Is there a documented or idiomatic way in Vert.x 4.x to re-evaluate authentication or permissions on an established WebSocket when the token expires, or is periodic re-authentication entirely the application's responsibility? Does vertx-auth-jwt expose configurable clock-skew leeway for exp validation in recent 4.x releases? And if we close the socket on expiry, what is the recommended way to signal the reason to the client?