(shamelessly splitting this into its own thread, but also to avoid
further derailment of Neustradamus' tls-exporter conversation)
On Fri, Nov 21, 2025 at 3:15 PM Nico Williams <nico@cryptonector.com> wrote:
> For apps like PG I'm much more interested in real OAuth support. But
> that's because I use PG in a corporate environment where we use
> Kerberos, PKIX, and OAuth for authentication.
Let us know what you think of PG18's OAuth support. We don't have
token binding (whether to the sender or to the channel), but I think
I'd rather put support behind something like an OAUTHDPOP-PLUS than
add bindings to OAUTHBEARER. (Though I still can't figure out whether
mTLS-constrained tokens are dead or not.)
> In particular I want the _client_ to be configurable to be smart enough
> as to how to fetch the darned OAuth rock the server wants.
libpq can be told to use a custom flow. psql, though, not yet... Only
the device flow for the utilities at the moment.
> I'm much
> more interested in OAuth for authentication than I am in OAuth for
> authorization -- GRANTs and RLS (and/or VIEWs that JOIN authz tables)
> are plenty good enough for authz in PG.
I think there might eventually be some interest in the latter, based
on some conversations I've had in the past few months, but I'm not
planning to work on that any time soon. (I think users would expect
central authz changes to take effect immediately, which is not going
to happen.)
--Jacob
