Re: Continuous re-validation of session credentials - Mailing list pgsql-hackers

From Ajit Awekar
Subject Re: Continuous re-validation of session credentials
Date
Msg-id CAER375O708DooXJ76O9cYWHD=EkKb9atojm2sH3YHhdHw4ZfCQ@mail.gmail.com
Whole thread
List pgsql-hackers
Hi,

Attached is v2 of the patch set, rebased on the current master.

The only functional change from the previous version is a fix for the
cfbot failure. The earlier version src/test/modules/test_misc/t/003_check_guc.pl
due to the tab in the trailing spaces.

Thanks & Best Regards,
Ajit


On Tue, 16 Jun 2026 at 17:44, Ajit Awekar <ajitpostgres@gmail.com> wrote:
Hi,

Today PG validates a client's credentials only once, at connection
time.  After that the backend runs until the client disconnects, even if the
basis for the original authentication decision has gone away.  In particular:

  - the role's VALID UNTIL passes, or the role is dropped (ALTER ROLE ...
    VALID UNTIL / DROP ROLE);
  - the OAuth bearer token the session authenticated with expires;
  - the TLS client certificate the session authenticated with reaches its
    notAfter date.

In all of these cases a long-lived session keeps running with credentials that
would be rejected on a fresh connection.  For environments with short-lived
credentials (OAuth tokens, short-lived certs, time-boxed accounts) this is a
real gap: revoking access has no effect on already-established sessions.

This patch series adds an optional mechanism to periodically re-validate the
credentials of an active session and terminate it (FATAL) once they are no
longer valid.

A per-backend timer (CREDENTIAL_VALIDATION_TIMEOUT) fires every
credential_validation_interval seconds and sets a pending flag.

Validation has two layers:
    - A baseline, auth-method-independent check (role still exists and has not
      passed rolvaliduntil), applied to every authenticated session.
    - Optional method-specific validators, registered via
      RegisterCredentialValidator(), for OAuth token expiry and client
      certificate expiry.

The framework is deliberately extensible: adding re-validation for a new
 authentication method needs only three small steps -- add a
 CredentialValidationType, implement a "bool validator(void)" callback that
 returns whether the credential is still valid, and register it with
 RegisterCredentialValidator().  The certificate and OAuth validators in 0002 
 and 0003 are  themselves examples of plugging into the framework this way, 
 so methods such  as LDAP, RADIUS, or GSSAPI/Kerberos credential lifetimes
 could be added later  without touching the core.

Two GUCs :
    credential_validation_enabled   (bool, default off)
    credential_validation_interval  (int, 5..3600 s, default 60)

Patch series
------------

  0001  Framework + baseline role-validity check (rolvaliduntil / role
        existence).  Useful on its own for password/md5/scram sessions.
  0002  TLS client certificate expiry.  The cert presented at connect time is
        retained on the Port, so its notAfter is re-checked locally with no
        network round-trip.
  0003  OAuth token expiry.  This adds an optional expire_cb callback to
        OAuthValidatorCallbacks; to stay ABI-compatible the validator magic is
        versioned (V1 = existing layout, V2 = adds expire_cb), and the server
        accepts both.

Request a review.


Thanks & Best Regards,
Ajit


Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_stat_statements: Remove (errcode...) framing parentheses in erport(...)
Next
From: Jeevan Chalke
Date:
Subject: Re: Add PRODUCT() aggregate function