Re: [OAuth2] Infrastructure for tracking token expiry time

Hi All,

I've added additional test cases to src/test/authentication/t/
008_continuous_validation.pl to improve coverage of the continuous
credential
validation feature.

Updated the README with:
- Fixed interval parameter
- Added a Testing section documenting all 6 test cases

- Added instructions for running the tests

Thanks & Best Regards,
Ajit

On Fri, 27 Mar 2026 at 16:29, Ajit Awekar <ajitpostgres(at)gmail(dot)com> wrote:

> Hi All,
>
> I'd like to propose a patch that adds a credential validation framework to
> PostgreSQL, enabling periodic re-validation of authentication
> credentials during active sessions.
>
> Currently, PostgreSQL validates credentials only at connection time. Once
> authenticated, a session remains valid even if the underlying
> credentials expire (e.g., a user's rolvaliduntil passes, or an OAuth token
> expires). This can be problematic in environments with strict
> security requirements where sessions should be terminated when credentials
> become invalid.
>
> This patch introduces a timer-based credential validation mechanism that
> periodically checks whether a session's authentication credentials are
> still valid. When credentials are found to be expired, the session is
> terminated with an appropriate error message
>
> *Key Components *
>
> 1. Core Framework (auth-validate.c, auth-validate.h)
> - Manages validation callbacks for different authentication methods
> - Provides a timeout-based scheduler using
> CREDENTIAL_VALIDATION_TIMEOUT
>
> - Handles validation status (CVS_VALID, CVS_EXPIRED, CVS_ERROR)
> 2. Validation Methods (auth-validate-methods.c)
>
> - Password validation: checks rolvaliduntil in pg_authid
>
> - OAuth validation: delegates to the validator module's new expire_cb
> callback
> 3. GUC Parameters
>
> - credential_validation.enabled (boolean, default: false)
> - credential_validation.interval (integer, 1-60 minutes, default: 1)
>
> *OAuth Validator Changes *
>
>
> The patch extends the OAuth validator API with an optional expire_cb
> callback. To maintain backward compatibility, the magic version has been
> bumped to PG_OAUTH_VALIDATOR_MAGIC_V2. Existing V1 validators continue
> to work; the server simply skips expiration checking for them.
>
>
> *Example Configuration*
> credential_validation.enabled = on
> credential_validation.interval = 5 # minutes
>
> Thanks & Best Regards,
> Ajit
>
>
> On Mon, 16 Mar 2026 at 19:27, Ajit Awekar <ajitpostgres(at)gmail(dot)com> wrote:
>
>> 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 <ajitpostgres(at)gmail(dot)com> 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 <zsolt(dot)parragi(at)percona(dot)com>
>>> 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.
>>>>
>>>