On Tue, Jun 16, 2026 at 1:22 PM Zsolt Parragi <[email protected]> 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
