Re: Periodic authorization expiration checks using GoAway message

Thanks a lot Jacob and Jelte for your valuable insights.

I agree that the seamless re-authentication model (re-authentication over
the active connection) is suited only for external centralized
authentication methods like OAuth2 and LDAP.

I have below questions

- Does the client need to pause current operations, execute a
simplified re-authentication sequence (triggered by the server's
Authentication Request), and then transparently resume the session upon
success?
- How frequently should the authorization expiration check occur in the
backend, Would the frequency be tied to a new session GUC (e.g.,
authorization_check_interval), allowing administrators to configure it?
- What should the behavior be for older version clients (backward
compatibility) that do not understand this new server-initiated
reauthentication message? In this case is the safest approach for the
server to terminate the connection?

Thanks & Best Regards,
Ajit

On Thu, 11 Dec 2025 at 02:50, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:

> On Wed, 10 Dec 2025 at 21:02, Jacob Champion
> <jacob(dot)champion(at)enterprisedb(dot)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(at)google(dot)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).
>