Re: [OAuth2] Infrastructure for tracking token expiry time

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.
>