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 <[email protected]> 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 > > >
0003-Add-OAuth-token-expiry-to-credential-validation.patch
Description: Binary data
0002-Add-TLS-client-certificate-expiry-to-credential-vali.patch
Description: Binary data
0001-Add-continuous-credential-validation-framework.patch
Description: Binary data
