(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 <[email protected]> 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
