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>
In-Reply-To: <CAN4CZFOe-0jTR7_s2uciX9TNKxRvd2h8avAw9iFO6VPu0CChsQ@mail.gmail.com>
From: Ajit Awekar <ajitpostgres@gmail.com>
Date: Tue, 17 Feb 2026 10:50:24 +0530
Message-ID: <CAER375Oh6U_kqP0SK8OP47vy3PBd4p1C027Gaod3B2bqKgMFoQ@mail.gmail.com>
Subject: Re: [OAuth2] Infrastructure for tracking token expiry time
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: VASUKI M <vasukianand0119@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/mixed; boundary="00000000000044e828064afe3b27"
Archived-At: <https://www.postgresql.org/message-id/CAER375Oh6U_kqP0SK8OP47vy3PBd4p1C027Gaod3B2bqKgMFoQ%40mail.gmail.com>
Precedence: bulk

--00000000000044e828064afe3b27
Content-Type: multipart/alternative; boundary="00000000000044e826064afe3b25"

--00000000000044e826064afe3b25
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Vasuki and Zsolt for your reply and comments.

>> First, is Port always zero-initialized? If not, we might want to
explicitly initialize the new expiry field to a known value. Right now it
looks like we=E2=80=99re relying on zero to mean =E2=80=9Cnot provided=E2=
=80=9D, but since
TimestampTz value 0 is a valid timestamp (Postgres epoch), I=E2=80=99m wond=
ering
whether it would be clearer to use an explicit invalid/sentinel value
instead.
I agree. The attached patch value is now initialised to
sentinel DT_NOBEGIN to indicate no expiry value has been provided yet.

>> Also, in the case where the validator returns an expiry that is already
in the past, should we reject the authentication immediately? Or is that
expected to be fully handled inside the validator module?
The design assumes that the Validator module will handle the immediate
rejection of tokens already in the past. The expiry field is intended for
the backend to manage session life after successful authentication

>> Finally, do you have a particular enforcement model in mind for
follow-up work (e.g., check at statement start, transaction boundaries, or
via some timeout mechanism)? It would help to understand how you see this
being used.
Ideally we should check this at statement start.

>> This API looks simple for providers that use JWT access tokens, but
what about providers that use opaque tokens and an introspection API
to check validity instead?
For providers using opaque tokens or introspection APIs where an 'exp'
claim might be missing, the API remains compatible by allowing the
validator to return DT_NOBEGIN.

Request a review.

Thanks & Best Regards,
Ajit

On Tue, 17 Feb 2026 at 01:10, Zsolt Parragi <zsolt.parragi@percona.com>
wrote:

> Hello
>
> This API looks simple for providers that use JWT access tokens, but
> what about providers that use opaque tokens and an introspection API
> to check validity instead? Some validators might not be able to
> provide anything meaningful without a periodic call to a "check
> validity now" method, and even some providers that use JWT access
> tokens support immediate revocation, where these periodic checks would
> be useful.
>

--00000000000044e826064afe3b25
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thanks Vasuki and Zsolt for your reply and comments.<=
/div><div><br></div><div>&gt;&gt;=C2=A0First, is Port always zero-initializ=
ed? If not, we might want to=20
explicitly initialize the new expiry field to a known value. Right now=20
it looks like we=E2=80=99re relying on zero to mean =E2=80=9Cnot provided=
=E2=80=9D, but since=20
TimestampTz value 0 is a valid timestamp (Postgres epoch), I=E2=80=99m wond=
ering
 whether it would be clearer to use an explicit invalid/sentinel value=20
instead.</div><div>I agree. The attached patch value is now initialised to =
sentinel=C2=A0DT_NOBEGIN=C2=A0to indicate no expiry value has been provided=
 yet.</div><div><br></div><div>&gt;&gt;=C2=A0Also, in the case where the va=
lidator returns an expiry that is already=20
in the past, should we reject the authentication immediately? Or is that
 expected to be fully handled inside the validator module?</div><div>The de=
sign assumes that the Validator module will handle the immediate rejection =
of tokens already in the past. The expiry field is intended for the backend=
 to manage session life after successful authentication</div><div></div><di=
v><br></div><div>&gt;&gt;=C2=A0Finally, do you have a particular enforcemen=
t model in mind for=20
follow-up work (e.g., check at statement start, transaction boundaries,=20
or via some timeout mechanism)? It would help to understand how you see=20
this being used.</div><div>Ideally we should check this at statement start.=
</div><div></div><div><br></div><div>&gt;&gt;=C2=A0This API looks simple fo=
r providers that use JWT access tokens, but<br>
what about providers that use opaque tokens and an introspection API<br>to =
check validity instead?</div><div>For providers using opaque tokens or intr=
ospection APIs where an &#39;exp&#39; claim might be missing, the API remai=
ns compatible by allowing the validator to return DT_NOBEGIN.</div><div><br=
></div><div>Request a review.</div><div><br></div><div>Thanks &amp; Best Re=
gards,</div><div>Ajit</div></div><br><div class=3D"gmail_quote gmail_quote_=
container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 17 Feb 2026 at 01:=
10, Zsolt Parragi &lt;<a href=3D"mailto:zsolt.parragi@percona.com">zsolt.pa=
rragi@percona.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">Hello<br>
<br>
This API looks simple for providers that use JWT access tokens, but<br>
what about providers that use opaque tokens and an introspection API<br>
to check validity instead? Some validators might not be able to<br>
provide anything meaningful without a periodic call to a &quot;check<br>
validity now&quot; method, and even some providers that use JWT access<br>
tokens support immediate revocation, where these periodic checks would<br>
be useful.<br>
</blockquote></div>

--00000000000044e826064afe3b25--
--00000000000044e828064afe3b27
Content-Type: text/x-patch; charset="US-ASCII"; name="password_expiry_oauth_V1.diff"
Content-Disposition: attachment; filename="password_expiry_oauth_V1.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_mlq5jmq00>
X-Attachment-Id: f_mlq5jmq00

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2xpYnBxL2F1dGgtb2F1dGguYyBiL3NyYy9iYWNrZW5k
L2xpYnBxL2F1dGgtb2F1dGguYwppbmRleCAxMTM2NTA0ODk1MS4uM2Y0NmFiNmI3YmMgMTAwNjQ0
Ci0tLSBhL3NyYy9iYWNrZW5kL2xpYnBxL2F1dGgtb2F1dGguYworKysgYi9zcmMvYmFja2VuZC9s
aWJwcS9hdXRoLW9hdXRoLmMKQEAgLTY4NCw2ICs2ODQsMTMgQEAgdmFsaWRhdGUoUG9ydCAqcG9y
dCwgY29uc3QgY2hhciAqYXV0aCkKIAkJZ290byBjbGVhbnVwOwogCX0KIAorCS8qCisJICogU3Rv
cmUgdGhlIHRva2VuIGV4cGlyYXRpb24gdGltZSBpbiB0aGUgUG9ydCBzdHJ1Y3R1cmUuIFRoaXMg
YWxsb3dzCisJICogdGhlIGJhY2tlbmQgdG8gZW5mb3JjZSBzZXNzaW9uIGxpbWl0cy5WYWxpZGF0
b3JzIHNob3VsZCBzZXQgdGhpcyB0bworCSAqIERUX05PQkVHSU4gaWYgbm8gZXhwaXJ5IGlzIGF2
YWlsYWJsZS4KKwkgKi8KKwlwb3J0LT5leHBpcnkgPSByZXQtPmV4cGlyeTsKKwogCWlmIChwb3J0
LT5oYmEtPm9hdXRoX3NraXBfdXNlcm1hcCkKIAl7CiAJCS8qCmRpZmYgLS1naXQgYS9zcmMvYmFj
a2VuZC9saWJwcS9wcWNvbW0uYyBiL3NyYy9iYWNrZW5kL2xpYnBxL3BxY29tbS5jCmluZGV4IDY1
NzBmMjcyOTdiLi5hZGQzODAwZmJkNCAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvbGlicHEvcHFj
b21tLmMKKysrIGIvc3JjL2JhY2tlbmQvbGlicHEvcHFjb21tLmMKQEAgLTMxOSw2ICszMTksMTIg
QEAgcHFfaW5pdChDbGllbnRTb2NrZXQgKmNsaWVudF9zb2NrKQogCUFzc2VydChzb2NrZXRfcG9z
ID09IEZlQmVXYWl0U2V0U29ja2V0UG9zKTsKIAlBc3NlcnQobGF0Y2hfcG9zID09IEZlQmVXYWl0
U2V0TGF0Y2hQb3MpOwogCisJLyoKKwkgKiBTZXQgdGhlIGluaXRpYWwgc2Vzc2lvbiBleHBpcnkg
dG8gRFRfTk9CRUdJTiB0byBpbmRpY2F0ZSBubyB2YWx1ZSBoYXMgYmVlbgorCSAqIHByb3ZpZGVk
IHlldC4KKwkgKi8KKwlwb3J0LT5leHBpcnkgPSBEVF9OT0JFR0lOOworCiAJcmV0dXJuIHBvcnQ7
CiB9CiAKZGlmZiAtLWdpdCBhL3NyYy9pbmNsdWRlL2xpYnBxL2xpYnBxLWJlLmggYi9zcmMvaW5j
bHVkZS9saWJwcS9saWJwcS1iZS5oCmluZGV4IDkyMWIyZGFhNGZmLi45YmM5NjI1ZDBiYSAxMDA2
NDQKLS0tIGEvc3JjL2luY2x1ZGUvbGlicHEvbGlicHEtYmUuaAorKysgYi9zcmMvaW5jbHVkZS9s
aWJwcS9saWJwcS1iZS5oCkBAIC0yMzgsNiArMjM4LDE0IEBAIHR5cGVkZWYgc3RydWN0IFBvcnQK
IAljaGFyCSAgICpyYXdfYnVmOwogCXNzaXplX3QJCXJhd19idWZfY29uc3VtZWQsCiAJCQkJcmF3
X2J1Zl9yZW1haW5pbmc7CisKKwkvKgorCSAqIFRoZSBleHBpcmF0aW9uIHRpbWUgb2YgdGhlIGF1
dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWwuIElmIG5vbi16ZXJvLCBpdAorCSAqIHJlcHJlc2VudHMg
dGhlIHBvaW50IGluIHRpbWUgYWZ0ZXIgd2hpY2ggdGhlIGN1cnJlbnQgc2Vzc2lvbiBpcyBjb25z
aWRlcmVkCisJICogaW52YWxpZC4KKwkgKi8KKwlUaW1lc3RhbXBUeiBleHBpcnk7CisKIH0gUG9y
dDsKIAogLyoKZGlmZiAtLWdpdCBhL3NyYy9pbmNsdWRlL2xpYnBxL29hdXRoLmggYi9zcmMvaW5j
bHVkZS9saWJwcS9vYXV0aC5oCmluZGV4IDRhODIyZTlhMWYyLi5mMTVmNzU5NzE4ZiAxMDA2NDQK
LS0tIGEvc3JjL2luY2x1ZGUvbGlicHEvb2F1dGguaAorKysgYi9zcmMvaW5jbHVkZS9saWJwcS9v
YXV0aC5oCkBAIC00OSw2ICs0OSwxMyBAQCB0eXBlZGVmIHN0cnVjdCBWYWxpZGF0b3JNb2R1bGVS
ZXN1bHQKIAkgKiBkZWxlZ2F0aW9uLiBTZWUgdGhlIHZhbGlkYXRvciBtb2R1bGUgZG9jdW1lbnRh
dGlvbiBmb3IgZGV0YWlscy4KIAkgKi8KIAljaGFyCSAgICphdXRobl9pZDsKKworCS8qCisJICog
VGhlIGV4cGlyYXRpb24gdGltZSBvZiB0aGUgdG9rZW4gKGUuZy4sIGZyb20gdGhlICdleHAnIGNs
YWltKS4KKwkgKiBJZiBwcm92aWRlZCwgdGhlIGJhY2tlbmQgY2FuIHVzZSB0aGlzIHRvIGxpbWl0
IHNlc3Npb24gZHVyYXRpb24uCisJICogVmFsaWRhdG9ycyBzaG91bGQgc2V0IHRoaXMgdG8gRFRf
Tk9CRUdJTiBpZiBubyBleHBpcnkgaXMgYXZhaWxhYmxlLgorCSAqLworCVRpbWVzdGFtcFR6IGV4
cGlyeTsKIH0gVmFsaWRhdG9yTW9kdWxlUmVzdWx0OwogCiAvKgo=
--00000000000044e828064afe3b27--