Hi, Please find the attached first version of the patch providing credential validation framework.
The credential validation framework provides a mechanism to continuously validate authentication credentials during an active session. This enables the server to periodically check credential validity and take appropriate action when credentials expire or become invalid. Currently, Postgres validates credentials only at connection time. Once authenticated, a session remains active even if: - A user's rolvaliduntil expiration time passes - An OAuth bearer token expires * Proposed Solution* The patch introduces a credential validation framework that: 1. Periodically checks credential validity during active sessions 2. Terminates sessions when credentials expire or become invalid *Implementation* The framework consists of: - Core infrastructure (auth-validate.c/h): Manages validation callbacks, dispatches validation checks based on authentication method - Method implementations (auth-validate-methods.c/h): Contains validators for password-based auth (checks rolvaliduntil in pg_authid) and OAuth (delegates to validator's expire_cb) Validation is triggered during query execution in both simple and extended query protocol paths, using a time-based approach to limit overhead. * Configuration* Two new GUC parameters: credential_validation.enabled = false # enable/disable validation credential_validation.interval = 1 # check interval in minutes (1-60) * Extensibility* New authentication methods can be supported by: 1. Adding an enum value to CredentialValidationType 2. Implementing a validation callback 3. Registering it via RegisterCredentialValidator() Should there be per-authentication-method enable/disable settings? Thanks & Best Regards, Ajit On Fri, 20 Feb 2026 at 15:12, Ajit Awekar <[email protected]> wrote: > > Thanks a lot Daniel, Zslot, Vasuki for your review comments. > > >The mechanism used is however a secondary discussion, > >first thing to get in place is a design for how to handle mid-connection > >credential expiration. > > This patch introduces a generic credential validation framework that > allows > us to periodically validate authentication credentials during active > database sessions. When enabled, this feature detects expired > credentials and terminates sessions that are no longer valid. > > Added GUCs > Credential_validation.enabled = on // Enable or Disable Credential > validation > Credential_validation.interval = 120 //Frequency in seconds of running > credential validation > > The callback mechanism works by: > - Defining a CredentialValidationCallback function pointer type > - Maintaining an array of validators indexed by authentication method > - Allowing other auth mechanisms to register validators via > RegisterCredentialValidator() > - Selecting the appropriate validator at runtime based on the session's > authentication method > > The current implementation primarily supports password-based > authentication methods, verifying that passwords haven't expired. It can be > extended to any authentication method. > This patch is WIP. I am submitting it now to get early feedback on the > overall design and approach. > > Thanks & Best Regards, > Ajit > > On Wed, 18 Feb 2026 at 22:29, Zsolt Parragi <[email protected]> > wrote: > >> > but I still think that neither should overload >> > what FATAL error means >> >> I see, I misunderstood what you meant by graceful there. In this case, >> this is also a good comment for the password expiration thread, >> currently that also uses FATAL errors for terminating a connection >> when the password expires. >> >> What other option do you see? Something new for this use case like >> GoAway, and clients not understanding it simply get disconnected after >> some grace period? Or using the recently merged connectionWarning to >> send a warning to the client, and disconnect it shortly if it doesn't >> do anything to fix the situation? >> >> When I tested the password expiration patch I noticed that deleted >> users who still have remaining active connections currently get ERRORs >> for every statement that requires permission checks, so in this regard >> using ERROR/FATAL for the situation seemed fine to me - it's similar >> to what already happens in some edge cases with authentication. >> >
credential_validation_V1.patch
Description: Binary data
