>What I meant that we can already implement a background process that >watches active (oauth) connections, and either:
>Revalidates tokens periodically using introspection APIs +1 as this will offload validation logic to a dedicated background process. Thanks & Best Regards, Ajit On Tue, 16 Dec 2025 at 13:35, Zsolt Parragi <[email protected]> wrote: > > I think this is related to the async concern and the "what is a client > > allowed to do before reauthentication" question. > > Yes, but my point was that I think the different situations (normally > expired token, we most likely still have a valid refresh token vs > token that was for some reason revoked before its normal expiration > date) are different and require different handling, I don't think we > should treat them the same way. GoAway seems to be more useful for the > first one. > > > (I don't see this as a message to be used during initial authentication.) > > What I meant that we can already implement a background process that > watches active (oauth) connections, and either: > > * Revalidates tokens periodically using introspection APIs > * Implements the Back-Channel logout[1] supported by several identity > providers > > And if the checks fail (a token is invalidated), we immediately close > the connection that uses the token. > > This situation can happen either when: > > a. The user presses the "logout everywhere" button > b. The users permissions change > c. The user is deactivated (e.g. employee termination) > d. A security check invalidates the user's session > > From these four, I think graceful logout/continuing the current query > is only an option for (a), maybe (b), for (c) and (d) we should log > out the user from everywhere as soon as possible. > > And even for the normal "logout" button, I can see graceful logout as > a potential option, but I'm not sure how many people would want it > instead of the normal "log out instantly" behavior. I think most > people would expect it to work exactly like a normal logout, like > closing psql. > > For (a) and (d) keeping the connection alive, but inactive, and > letting the user log in again without losing the session could be an > option, and GoAway could be useful there if I understand correctly. > For (b) and (c) there's no way for the session to continue. But > because of (d) I think it is important to terminate the query > immediately (or at least: prevent committing, but that seems more > difficult to do), I don't think anybody would want graceful > termination in case of a security incident. > > On the other hand, if the access token expires, and we have to > automatically/manually get a new one, I imagine most people would > want/expect graceful behavior. > > [1] https://openid.net/specs/openid-connect-backchannel-1_0.html >
