MIME-Version: 1.0
References: <CAER375PhG5an=p1=6QS6vWi=BHxR+ViJmYPDkkEtpgVsfCcu_w@mail.gmail.com>
 <CAE2r8H5QAng_rRrkVmGbLuQSgbMz94tpOOOdJKeuHj=go0nXqg@mail.gmail.com>
 <CAN4CZFOe-0jTR7_s2uciX9TNKxRvd2h8avAw9iFO6VPu0CChsQ@mail.gmail.com>
 <CAER375Oh6U_kqP0SK8OP47vy3PBd4p1C027Gaod3B2bqKgMFoQ@mail.gmail.com>
 <CAN4CZFNV69LS6H87sV-iPO9w_V-_uko4_G_0QKb1cokJvWhF6g@mail.gmail.com>
 <CAE2r8H6Tc6F2BM-JqC+gp-HQKCzfHOx02Xj5MmuS-AY4jfN5iw@mail.gmail.com>
 <CAER375Mtf-7LcR1zNks67k57r3b5yTy9sHxRQ78Y1+xmTVncMw@mail.gmail.com> <D3C75650-2FED-41B3-A6BF-E4D8F9E40EAE@yesql.se>
In-Reply-To: <D3C75650-2FED-41B3-A6BF-E4D8F9E40EAE@yesql.se>
From: Zsolt Parragi <zsolt.parragi@percona.com>
Date: Wed, 18 Feb 2026 12:04:13 +0000
Message-ID: <CAN4CZFPKY2m1bEm51g-1jmBfCMohfe5VFoKuCnbhiGP1FBBNrQ@mail.gmail.com>
Subject: Re: [OAuth2] Infrastructure for tracking token expiry time
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Ajit Awekar <ajitpostgres@gmail.com>, VASUKI M <vasukianand0119@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAN4CZFPKY2m1bEm51g-1jmBfCMohfe5VFoKuCnbhiGP1FBBNrQ%40mail.gmail.com>
Precedence: bulk

> Also, why is this defined in ValidatorModuleResult?  If I interpret Zsolt's
> comment upthread correctly it was meant to be placed in OAuthValidatorCallbacks
> as a new callback - which I agree with would be better.  The question of where
> and when to invoke it remains, but whatever we build I think it should be auth
> agnostic so that any auth can be hooked into it.

+1 Yes, that's what I meant. Also agree with the unnecessary expiry
timestamp with the callback - if we want to store some additional data
for the checks, that should be a void*, but with the single threaded
model there's no real need for it, the validator can store anything it
needs in global variables.

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

There was an earlier discussion about it in the password expiration
thread[1], and the possible use of the GoAway[2] for it. Jacob
suggested making it user configurable, which seems like a reasonable
way to do it.

I also wanted to work on this patch, but I didn't start working on it
so far, because I wanted to see where those threads go, as the changes
introduced in them could be useful for the oauth token
refresh/disconnection mechanism.

[1] : https://www.postgresql.org/message-id/flat/CAER375OvH3_ONmc-SgUFpA6gv_d6eNj2KdZktzo-f_uqNwwWNw%40mail.gmail.com
[2] : https://www.postgresql.org/message-id/flat/DDPQ1RV5FE9U.I2WW34NGRD8Z%40jeltef.nl