Re: [OAuth2] Infrastructure for tracking token expiry time - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: [OAuth2] Infrastructure for tracking token expiry time
Date
Msg-id 7F3C1A8B-F0FF-49BF-A53C-DC043BBB1FE7@yesql.se
Whole thread Raw
In response to Re: [OAuth2] Infrastructure for tracking token expiry time  (Zsolt Parragi <zsolt.parragi@percona.com>)
Responses Re: [OAuth2] Infrastructure for tracking token expiry time
List pgsql-hackers
> On 18 Feb 2026, at 13:04, Zsolt Parragi <zsolt.parragi@percona.com> wrote:

>> 2. Terminating sessions with expired/revoked tokens before executing new
>> commands.
>
>> Token expiration is IMHO not a use case for a FATAL error, if we want to
>> terminate a connection we can do it in a more graceful way.
>
> There are different reasons for token expiration, one is a simple
> timeout where all we have to do is communicate to the client that we
> need a refresh (gracefully), and the other is where a token is
> immediately revoked because of a security incident, in which case
> immediate termination is a good practice.

I understand these cases and agree that there are different needs for messaging
to the user for these cases, but I still think that neither should overload
what FATAL error means.  The mechanism used is however a secondary discussion,
first thing to get in place is a design for how to handle mid-connection
credential expiration.

--
Daniel Gustafsson




pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Killing off anoncvs.postgresql.org
Next
From: Andres Freund
Date:
Subject: Re: Lowering the default wal_blocksize to 4K