> On 18 Feb 2026, at 09:38, Ajit Awekar <[email protected]> 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 == 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
