Re: Require SSL connection to postgres for oauth

On Wed, Jun 17, 2026 at 12:23 AM Zsolt Parragi
<zsolt(dot)parragi(at)percona(dot)com> wrote:
> * It requires OAUTHDEBUG=UNSAFE to use http instead of https to get
> the token. The documentation makes it clear that this option is unsafe
> because it transmits authentication data in clear-text

The HTTPS communication uses the web model of security, yes. I was
pretty adamant about that during development.

But the communication with the server uses the Postgres model of
security, which unfortunately puts more requirements on end users.
Using OAuth does not move you into a stronger security model. For now,
it's still up to the DBA to enforce TLS in the HBA, and for the client
to set require_auth and sslmode appropriately. This is true of all
authentication types (which is bad, IMNSHO) so I'd like to strengthen
that for everybody who uses the server and not just OAuth users.

(Having different transport-security defaults for different authn
types is probably not a net win, since users have to keep it all
straight in their heads. It's a similar argument to the one we had re:
HBA configuration -- it's easier to make changes to OAuth in
isolation, but really we want the same functionality/policies to be
available for all of our authentication types. Even getting
sslrootcert=system to behave the way it does was a matter of debate,
though I still think we made the right call there.)

> Another thing is that users usually aren't aware that oauthbearer
> requires TLS, and just trust the implementation. SCRAM doesn't have
> this requirement

It absolutely *does* have that requirement! If you need connection
security, do NOT use SCRAM without authenticated transport encryption.
Untrusted connection without TLS isn't part of the supported security
model, which is why strengthening SCRAM for those use cases is
discussed in public [1] rather than under a CVE fix.

I'd like to get to the point where that's safe, because I think it's
really strange that you can't safely use a mutual authentication tech
as your sole method of server authentication, but we're not there.

> > 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.
>
> Is this a common-enough use case to think about?

I've asked a colleague who knows more about the cloud-y and k8s cases
to weigh in with their experience here, if possible. All I'll be
capable of is handwaving.

> Even within a
> "trusted" infrastructure, sending passwords in cleartext seems wrong
> to me.

I think it is too. But I don't control other people's infrastructure,
and I can't prove that a lack of TLS is equivalent to cleartext.

> As an alternative idea, what do you think about requiring an
> explicitly specified sslmode=disable in the connection string? That
> would also fit into the error message of my current patch, we could
> even modify it to "consider sslmode=require or specify sslmode=disable
> to override"

I think it's reasonable for a sufficiently informed user to choose
"don't care" as an option. (I just don't think it should be the
*default* for any connection, as it is today. Certainly not a
connection in which a secret is being sent.) So I don't think this
improves things, personally... and if sslmode=system were the global
default, we'd likely not be having this conversation at all.

> > One big alternative I can think of: I plan to push on file-based libpq
> > configuration
>
> That would definitely be a better fit, but I was hoping this could be
> fixed even in earlier branches, as this can be potentially dangerous.
> However, given the compatibility concern that seems unlikely.

Since it was an explicit decision rather than an oversight, I think
you'd have a hard time overcoming the backport barrier without a
really strong consensus.

--Jacob

[1] https://postgr.es/m/CAH7T-aqV9KVuO2yCpzTM2E0Pz=yJOMhK1PyAGt=od77_OztBVg@mail.gmail.com