Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.2\))
Subject: Re: [OAuth2] Infrastructure for tracking token expiry time
From: Daniel Gustafsson <daniel@yesql.se>
In-Reply-To: <CAER375Mtf-7LcR1zNks67k57r3b5yTy9sHxRQ78Y1+xmTVncMw@mail.gmail.com>
Date: Wed, 18 Feb 2026 11:34:01 +0100
Cc: VASUKI M <vasukianand0119@gmail.com>,
 Zsolt Parragi <zsolt.parragi@percona.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D3C75650-2FED-41B3-A6BF-E4D8F9E40EAE@yesql.se>
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>
To: Ajit Awekar <ajitpostgres@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/D3C75650-2FED-41B3-A6BF-E4D8F9E40EAE%40yesql.se>
Precedence: bulk

> On 18 Feb 2026, at 09:38, Ajit Awekar <ajitpostgres@gmail.com> wrote:

> I have added a unit test case to validate that sessions are properly =
terminated when their OAuth tokens expire.

+	/*
+	 * If the current session was authenticated via OAuth, verify =
that the
+	 * token has not expired or been revoked before executing the =
query.
+	 */
+	if (MyClientConnectionInfo.auth_method =3D=3D uaOAuth)
+		check_oauth_expiry(MyProcPort);

This seems too expensive and invasive in these codepaths and also not in =
line
with how other authentication methods are handled, we for example don't =
check
if a client certificate has been revoked in a similar manner.  I don't =
think it
would be bad if we could detect expired credentials mid-flight but I =
think it
would need to be done smarter than sprinkling auth specific checks like =
this.

+		ereport(FATAL,
+				=
(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
+				 errmsg("session expired: OAuth token is =
no longer valid")));

Token expiration is IMHO not a usecase for a FATAL error, if we want to
terminate a connection we can do it in a more graceful way.

+	/*
+	 * Optional callback to check if the session is still valid.
+	 * Returns true if the token is expired/revoked, false =
otherwise.
+	 * If NULL, the backend assumes the session never expires.
+	 * If provided, the validator can use this to limit session =
duration based on
+	 * parameter value or based on it's custom logic.
+	 */
+	bool (*expired_cb) (TimestampTz expiry);
+
+	/*
+	 * The expiration time of the token (e.g., from the 'exp' claim) =
if
+	 * provided. This value is passed as an argument to the =
expired_cb function
+	 * above to determine if the session should terminate.
+	 */
+	TimestampTz expiry;
 } ValidatorModuleResult;

What's the point of having an expiry timestamp as well as an expiration =
check
callback?  Wouldn't that open up for the caller to make its own judgment =
on
expiration which might conflict with expired_cb?  Is token expiration =
really
always tied to a timestamp for all types of tokens?

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.

--
Daniel Gustafsson