Re: Periodic authorization expiration checks using GoAway message

>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 <zsolt(dot)parragi(at)percona(dot)com>
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
>