Обсуждение: Periodic authorization expiration checks using GoAway message

Also have not looked at the patch, but we should also make sure that
there is not just be GoAway, but also a way to re-authenticate or
"extend lease" or whatever the terminology is for a specific
authentication method.

So maybe the message should be ReAuthentiocateOrElse" ?

On Fri, Nov 28, 2025 at 6:19 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
>
> On Fri, Nov 28, 2025, 04:39 Ajit Awekar <ajitpostgres@gmail.com> wrote:
>>
>> This patch depends on the "GoAway" protocol message proposal currently under review here:
https://www.postgresql.org/message-id/DDPQ1RV5FE9U.I2WW34NGRD8Z%40jeltef.nl Please apply this patch on top of the
GoAwaypatch. 
>
>
> A review of the GoAway patch from you would definitely be appreciated (even if there's no actionable feedback like:
"thislooks good and I managed use it for my own patch successfully") 
>
>> The Solution: To handle this authorization gap gracefully, this patch leverages the pending GoAway protocol message
tonotify clients. 
>
>
> I didn't look at the patch (I'm on my phone). But my first thought is that only relying on the proposed version of
GoAwayis insufficient for anything related to security. The GoAway message is both best effort, and only supported with
newerprotocol versions. So while I think it's a good usecase for GoAway, I think there *also* needs to be a hard
timeoutat which point the connection gets forcefully terminated if it's using old credentials. 
>
> Regarding the configurable interval that you describe for checking auth changes, I think it might be better to
registera SysCache update receiver instead (or just poll the SysCache value 
>
> Finally, can you register this patch on the commitfest? https://commitfest.postgresql.org/

(To call it out explicitly: I work with Ajit, and I asked him to take
a look at GoAway, and I'm particularly interested in the
"reauthenticate or else" case. Let me know if any of that is
problematic -- or if anyone's worried that it will become so -- so I
can course-correct sooner rather than later.)

On Fri, Nov 28, 2025 at 9:52 AM Hannu Krosing <hannuk@google.com> wrote:
> Also have not looked at the patch, but we should also make sure that
> there is not just be GoAway, but also a way to re-authenticate or
> "extend lease" or whatever the terminology is for a specific
> authentication method.

I agree. I like the idea of the server coordinating (and then
enforcing) connection lifetime and cross-connection handoffs with the
client, but like Jelte said, the current GoAway proposal isn't really
built for that.

Is there enough interest in the more general problem for us to try
combining the use cases? Or should they remain separate?

Thanks,
--Jacob

On Wed, 10 Dec 2025 at 21:02, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> (To call it out explicitly: I work with Ajit, and I asked him to take
> a look at GoAway, and I'm particularly interested in the
> "reauthenticate or else" case. Let me know if any of that is
> problematic -- or if anyone's worried that it will become so -- so I
> can course-correct sooner rather than later.)

I think password rollover without downtime requires more thought than
discussed in this thread so far. Currently the simplest way (that I
know of) to rollover passwords without downtime is to have two users
that you can switch between, and one has been configured with:
ALTER USER b SET ROLE = a;

So both effectively log in as a.

Reading between the lines, I guess you're looking at this from the
OAuth lens. Not "normal" passwords.

> On Fri, Nov 28, 2025 at 9:52 AM Hannu Krosing <hannuk@google.com> wrote:
> > Also have not looked at the patch, but we should also make sure that
> > there is not just be GoAway, but also a way to re-authenticate or
> > "extend lease" or whatever the terminology is for a specific
> > authentication method.
>
> I agree. I like the idea of the server coordinating (and then
> enforcing) connection lifetime and cross-connection handoffs with the
> client, but like Jelte said, the current GoAway proposal isn't really
> built for that.

If you want to re-authenticate over the existing connection (and
keeping your session etc), then I think that's a very different thing
than what I intended the GoAway message to be used for.

> Is there enough interest in the more general problem for us to try
> combining the use cases? Or should they remain separate?

I'm not sure what you mean with "combine the use cases". If you think
the GoAway protocol message definition could be extended slightly to
better serve this use case somehow. For instance if you think we
should have the GoAway message include an (optional) number of
seconds, so a client could say to the user: "Disconnect within 6
minutes". (just an example, not necessarily something I think is a
good idea)

If you mean combining by introducing a single shared protocol message
for both the "re-authenticate on existing session" and "please
reconnect asap", then I'd say: No, let's keep them separate.

I think for "re-authenticate now on existing connection" it'd be much
more natural for the server to simply send a new authentication
request message, and expect the client to respond to that. The auth
flow based on these messages is already implemented by each client,
they'd only need to change it so that it could be called into at any
moment (or maybe certain defined moments like in between queries).

On Wed, Dec 10, 2025 at 1:21 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> I think password rollover without downtime requires more thought than
> discussed in this thread so far.

Sure. See also

    https://postgr.es/m/CAGB%2BVh5SQQorNDEKP%2B0G%3DsmxHRhbhs%2BVkmQWD5Vh98fmn8X4dg%40mail.gmail.com

> Reading between the lines, I guess you're looking at this from the
> OAuth lens.

Yes. Or Kerberos.

> Not "normal" passwords.

I could see a case for kicking connections after a SCRAM password
change, if they're not able to reauthenticate in X interval. But I
wouldn't make it my top priority, necessarily.

> > Is there enough interest in the more general problem for us to try
> > combining the use cases? Or should they remain separate?
>
> I'm not sure what you mean with "combine the use cases". If you think
> the GoAway protocol message definition could be extended slightly to
> better serve this use case somehow.

Just that the two cases of "please consider reconnecting due to a
topology change" and "you didn't reauthenticate in time, so now you
_have_ to reconnect, bye" seem like they might be related at the
protocol level, since some types of topology changes might warrant a
harsher approach, and some types of authentication might do well with
a gentler one.

> If you mean combining by introducing a single shared protocol message
> for both the "re-authenticate on existing session" and "please
> reconnect asap", then I'd say: No, let's keep them separate.

Agreed; I did not mean that.

> I think for "re-authenticate now on existing connection" it'd be much
> more natural for the server to simply send a new authentication
> request message, and expect the client to respond to that. The auth
> flow based on these messages is already implemented by each client,
> they'd only need to change it so that it could be called into at any
> moment (or maybe certain defined moments like in between queries).

I think that's probably the hard part. "in between" is not
particularly well-defined, especially once you add in some async
pipelining, right? Contrast with HTTP/3's GOAWAY, especially its
graceful shutdown flow.

--Jacob

On Thu, Dec 11, 2025 at 2:52 AM Ajit Awekar <ajitpostgres@gmail.com> wrote:
> I agree that the seamless re-authentication model (re-authentication over the active connection) is suited only for
externalcentralized authentication methods like OAuth2 and LDAP. 

Well, see my response to Jelte above. But I think it's certainly
easier to pitch the usefulness of the feature for external methods.

> Does the client  need to pause current operations, execute a simplified re-authentication sequence (triggered by the
server'sAuthentication Request), and then transparently resume the session upon success? 

I think it would have to. But we don't number our conversations like
the other protocols with GOAWAY do, so it's not immediately clear to
me how we would do it.

The reauthentication sequence isn't guaranteed to be silent, either.
Imagine that you were typing a SQL command and psql popped up a
password prompt right in the middle; that's not a good user
experience.

> How frequently should the authorization expiration check occur in the backend, Would the frequency be tied to a new
sessionGUC (e.g., authorization_check_interval), allowing administrators to configure it? 

I don't think there's one answer, so it'd probably have to be
configurable. Offline tokens and Kerberos tickets might have a known
timestamp for expiration, so you could just do a cheap timestamp
comparison for every single request. Online checks (to allow
revocation) would need more thought by the DBA; there's a
performance-staleness tradeoff there.

> What should the behavior be for older version clients (backward compatibility)  that do not understand this new
server-initiatedreauthentication message? In this case is the safest approach for the server to terminate the
connection?

"Safe" is decided by the DBA, I think. Turning this on might imply
that you care more about security than the cost of cleaning up after a
client that got kicked off halfway through an important transaction...
or it might not.

--Jacob

On Fri, 12 Dec 2025 at 01:10, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>     https://postgr.es/m/CAGB%2BVh5SQQorNDEKP%2B0G%3DsmxHRhbhs%2BVkmQWD5Vh98fmn8X4dg%40mail.gmail.com

Thanks, I hadn't seen that one before.

> "you didn't reauthenticate in time, so now you
> _have_ to reconnect, bye"

I might be missing something but I feel like we currently do this in
various other places using:
FATAL: <message explaining reason>
<connection close>

> I think that's probably the hard part. "in between" is not
> particularly well-defined, especially once you add in some async
> pipelining, right?

Yeah, pipelining is annoying for these kind of things. But looking
it's not so bad. What if you define the flow as:
1. server sends 'R' message when it realizes it wants a
re-authentication (allowed whenever, just like NoticeResponse)
2. client can continue to send whatever and server will respond accordingly
3a. client starts authentication flow by sending a 'p' message
3b. client did not complete auth flow within timeout of the server, so
server sends FATAL + closes connection.

Would client side revalidation allow re-authentication while a
long-running query is in progress? Or would it kick out a connection
because it can't reauthenticate after some grace period? A strict OIDC
setup might use 5 or 10 minute access tokens, where this is a
realistic issue.

> 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 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. 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.

On Thu, Dec 11, 2025 at 4:36 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> > "you didn't reauthenticate in time, so now you
> > _have_ to reconnect, bye"
>
> I might be missing something but I feel like we currently do this in
> various other places using:
> FATAL: <message explaining reason>
> <connection close>

Part of the appeal to me is the ability for the client to decide to
transparently reconnect if possible, rather than surfacing an error to
the user. But if there's no other metadata to be used by the client
during that, then I suppose we could create a new 08Pxx SQLSTATE to
mean that. That does cover the backwards compatibility angle pretty
well.

> Yeah, pipelining is annoying for these kind of things. But looking
> it's not so bad. What if you define the flow as:
> 1. server sends 'R' message when it realizes it wants a
> re-authentication (allowed whenever, just like NoticeResponse)
> 2. client can continue to send whatever and server will respond accordingly
> 3a. client starts authentication flow by sending a 'p' message
> 3b. client did not complete auth flow within timeout of the server, so
> server sends FATAL + closes connection.

I think a timeout-based flow (though simple!) might be hard to
maintain for a DBA. It's basically a race condition that they would
have to tune. (I'm not saying I'm opposed to a timeout here; just that
the timeout should be a backstop for a misbehaved client, rather than
the thing the conversation is based on. The client should know what
it's allowed to finish up before reauthenticating.)

--Jacob

On Mon, 15 Dec 2025 at 18:17, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> Part of the appeal to me is the ability for the client to decide to
> transparently reconnect if possible, rather than surfacing an error to
> the user. But if there's no other metadata to be used by the client
> during that, then I suppose we could create a new 08Pxx SQLSTATE to
> mean that. That does cover the backwards compatibility angle pretty
> well.

Seems reasonable to use dedicated error code for that. My
understanding (see below) would be that getting this error would be
the exception, because in the happy path the client would
re-authenticate on the existing connection.

> > Yeah, pipelining is annoying for these kind of things. But looking
> > it's not so bad. What if you define the flow as:
> > 1. server sends 'R' message when it realizes it wants a
> > re-authentication (allowed whenever, just like NoticeResponse)
> > 2. client can continue to send whatever and server will respond accordingly
> > 3a. client starts authentication flow by sending a 'p' message
> > 3b. client did not complete auth flow within timeout of the server, so
> > server sends FATAL + closes connection.
>
> I think a timeout-based flow (though simple!) might be hard to
> maintain for a DBA. It's basically a race condition that they would
> have to tune. (I'm not saying I'm opposed to a timeout here; just that
> the timeout should be a backstop for a misbehaved client, rather than
> the thing the conversation is based on. The client should know what
> it's allowed to finish up before reauthenticating.)

To clarify: I meant the timeout as a backstop in this flow. Once the
client receives a 'R' message it should be re-authenticating ASAP. But
if it still had some messages in flight, the server can still choose
to process them during a grace period.

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

On Mon, Dec 15, 2025 at 9:28 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> To clarify: I meant the timeout as a backstop in this flow. Once the
> client receives a 'R' message it should be re-authenticating ASAP. But
> if it still had some messages in flight, the server can still choose
> to process them during a grace period.

But it seems iffy to change authentication metadata associated with
the connection halfway through a transaction, no? Am I missing
something that makes that architecturally safe?

--Jacob

On Mon, 15 Dec 2025 at 18:31, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> But it seems iffy to change authentication metadata associated with
> the connection halfway through a transaction, no? Am I missing
> something that makes that architecturally safe?

It felt a bit iffy to me too initially, but then I started looking at
it from the other direction: i.e. what am I missing that actually
makes this architecturally unsafe? And I cannot think of anything.

I see two possible things happening when re-authenticating mid-transaction:
1. User re-authenticates correctly, the transaction can continue as it
would normally
2. User re-authenticates incorrectly, connection is closed and
transaction is aborted

Both of those situations seem totally reasonable to me. What metadata
are you worried about changing mid transaction that could mess stuff
up? The primary one I can imagine is the username, but in my proposed
implementation of the feature that one would have to stay the same
anyway: The authentication related messages ('R' and 'p') don't
contain username, that's part of the StartupMessage.

> 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