Re: [oauth] Per connection auth hooks in libpq

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [oauth] Per connection auth hooks in libpq
Date: 2026-02-27 00:42:43
Message-ID: CAOYmi+k4wViip45Qi3Hc45EmzDWSCUhvgb5Os-gSgYavq3goFQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 26, 2026 at 3:36 PM Andreas Karlsson <andreas(at)proxel(dot)se> wrote:
> So attached is a proof of concept patch which implements a
> per-connection hook. It is just a rough patch to start a discussion. If
> people like it I can clean it up and add tests and documentation.

Thank you! So let me start by saying I agree that global is bad, and
per-connection is what we would ideally allow. The original patchset
started out with per-connection settings (for what eventually became
PQAUTHDATA_PROMPT_OAUTH_DEVICE, if I recall correctly).

But I quickly ran into chicken-and-egg problems. We don't expose the
ability to get a connection handle before the connection attempt
starts, nor do we expose the ability to synchronously finish a
connection that's already been started. (So you're locked into
polling-only if you want this.)

You can argue that PQconnectStart() *currently* always returns before
writing its first data, but I feel uncomfortable pinning that
implementation detail for OAuth alone (unless the senior maintainers
are fine with it?). It's already odd, in my mind, that we return
before knowing that polling is even necessary, and I think somebody
might reasonably change that (on purpose, or not) in the future,
especially if PQconnectPoll() ever gets rewritten like I'm hoping.

Not providing a clear "setopt" operation on an empty PGconn is
reminding me of my complaint that we put both application settings and
network settings into the connection string [1], which is reminding me
of Zsolt's complaint that it's difficult to establish security
boundaries for connection settings in the face of environment
variables [2], which recalls earlier discussions with Tom around
sslkeylogfile [3]. This is like an evil twin to the HBA-setting
problem. I think ideally these _would_ be solved with a single
coherent plan, but is there a way to tackle it incrementally...?

Thanks,
--Jacob

[1] https://postgr.es/m/CAOYmi%2BnQu-X7rL3GAB%3Dz2p7qLS4RrNARsz5VSagx%3D3q%2Bh_03zg%40mail.gmail.com
[2] https://postgr.es/m/CAOYmi%2BmVX5rKfvsCVVYM8ZDEBaNDO83TBLPURFuEgA8gbsU8Zw%40mail.gmail.com
[3] https://postgr.es/m/1774813.1736385450%40sss.pgh.pa.us

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-02-27 00:53:58 Defects with invalid stats data for expressions in extended stats
Previous Message Andreas Karlsson 2026-02-26 23:35:31 [oauth] Per connection auth hooks in libpq