Re: Periodic authorization expiration checks using GoAway message

> 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