Re: [OAuth2] Infrastructure for tracking token expiry time

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: Ajit Awekar <ajitpostgres(at)gmail(dot)com>, VASUKI M <vasukianand0119(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [OAuth2] Infrastructure for tracking token expiry time
Date: 2026-02-18 16:30:24
Message-ID: 7F3C1A8B-F0FF-49BF-A53C-DC043BBB1FE7@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 18 Feb 2026, at 13:04, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-02-18 16:32:28 Re: Lowering the default wal_blocksize to 4K
Previous Message Daniel Gustafsson 2026-02-18 16:21:10 Re: Killing off anoncvs.postgresql.org