On Tue, Jun 16, 2026 at 1:22 PM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> Additionally, for the two
> mechanisms specified in this document, TLS MUST be used for
> OAUTHBEARER to protect the bearer token; for OAUTH10A, the use of TLS
> is RECOMMENDED.
Yeah. Implementing this was discussed in-person a few times (not sure
if it made the lists), and IIRC the reaction at the time was
neutral-to-negative. Historically, Postgres lets you send credentials
in plaintext and assumes you know what you're doing. But things
change, and I wouldn't mind enforcing this if there's consensus.
We would still need to consider compatibility, though. I keep hearing
people talk about running infrastructure within "trusted" TCP (I
assume via a mesh or cloud VPN of some sort?) and I don't know that
they should be made to use a debug flag.
> What do you think about extending the already existing
> OAUTHDEBUG=UNSAFE... libpq flags to require something like
> "UNSAFE:plaintext-server" if somebody really wants to use it over a
> plaintext protocol?
One big alternative I can think of: I plan to push on file-based libpq
configuration [1] again for PG20, after multiple PGConf.dev
conversations for independent features ended up at "it'd be really
nice if we could configure this behavior outside of a connection
string". This would fit really nicely there: we could make the default
stricter while still giving people an easy out if they don't like it,
*and* we could discuss applying it to all secrets.
But a simpler way to toggle it for OAuth would be a good first step
and fallback, if that doesn't land.
> See attached patch:
(reminder to register in CF if you haven't already)
> We could argue that we should also allow GSSAPI
We should allow gssenc, yeah, unless you know of a reason that
gssenc+OAuth doesn't work today? (If it doesn't, that's unintentional
and I need to look into it.)
> Should we also add a
> matching warning on the server side during startup or HBA reload if we
> find OAuth entries that do not use SSL?
IMO, yes (especially if the client default were to change). In fact we
could consider adding that regardless of whether the client side
change gets committed.
Thanks,
--Jacob
[1] https://postgr.es/m/CAOYmi%2BmhiTPmNxy9JDKh%2BpahDxz2OoxAf%3D-jq%2BG%2BYUkHHqAGUA%40mail.gmail.com
