On Fri, Dec 12, 2025 at 3:49 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> Would client side revalidation allow re-authentication while a
> long-running query is in progress?
I think this is related to the async concern and the "what is a client
allowed to do before reauthentication" question.
> > Online checks (to allow revocation) would need more thought by the DBA; there's a performance-staleness tradeoff
there.
>
> Are revocation checks really related to GoAway? Even with offline OIDC
> tokens, we can implement periodic server side checks to see if a long
> lived token is still alive using an introspection endpoint.
I view it as related (potentially) to the continuity of the connection
handoff, if the client doesn't reauthenticate. The revocation itself
doesn't have much to do with GoAway.
> I think this should be already possible with current validators, by
> closing the connection if we find out that a token was revoked -
> trying to implement this is on my TODO list.
(I don't see this as a message to be used during initial authentication.)
> Should we really handle
> this through GoAway, and allow a graceful period? If a token was
> revoked, there's usually a good reason for that.
What to do with a token that's revoked while a
connection/query/transaction is in progress is a big design decision,
I think. But I could see a case for defaulting to graceful
reauthentication even in the case of OAuth revocation.
If you're worried about a single bearer token, you can revoke it
(clients can still refresh them and keep going). If you're worried
about a refresh token, you can revoke it (clients might ask users for
another one and keep going). And if you're worried about a client, you
can revoke its ability to access the required scopes, and then you've
locked it out. The protocol doesn't necessarily need to care that the
graceful reauthentication is doomed to failure.
--Jacob
