public inbox for [email protected]
help / color / mirror / Atom feedFrom: Zsolt Parragi <[email protected]>
To: Daniel Gustafsson <[email protected]>
Cc: Ajit Awekar <[email protected]>
Cc: VASUKI M <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: [OAuth2] Infrastructure for tracking token expiry time
Date: Wed, 18 Feb 2026 12:04:13 +0000
Message-ID: <CAN4CZFPKY2m1bEm51g-1jmBfCMohfe5VFoKuCnbhiGP1FBBNrQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
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>
<[email protected]>
> 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%40mai...
[2] : https://www.postgresql.org/message-id/flat/DDPQ1RV5FE9U.I2WW34NGRD8Z%40jeltef.nl
view thread (11+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [OAuth2] Infrastructure for tracking token expiry time
In-Reply-To: <CAN4CZFPKY2m1bEm51g-1jmBfCMohfe5VFoKuCnbhiGP1FBBNrQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox