> Historically, Postgres lets you send credentials > in plaintext and assumes you know what you're doing.
Yes, but if we look at the oauth part: * 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 * We also want to add a reminder to the unsafe trace output that warns users that the trace contains sensitive authentication data, do not share it with others * But then if the configuration specifies a plaintext connection to postgres, it silently accepts and uses it. It isn't mentioned anywhere that this is a bad idea. Another thing is that users usually aren't aware that oauthbearer requires TLS, and just trust the implementation. SCRAM doesn't have this requirement, so we can't even say something like "use TLS with SASL", it depends on the mechanism. > 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? Even within a "trusted" infrastructure, sending passwords in cleartext seems wrong to me. I used OAUTHDEBUG because I wanted to keep backward compatibility (but my main reasoning was easier testing, not actual production use), and it was an already existing environment variable also used by the http/https switch. I didn't want to introduce a new environment variable for this purpose, and I also didn't want to introduce a new connection option. 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" > 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. > 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.) No, I only left it out from it because the RFC explicitly requires TLS. v2 also permits gss. > 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. Also attached 0002, which adds the server side warning.
v2-0002-Warn-when-OAuth-is-configured-on-plaintext-capable-H.patch
Description: Binary data
v2-0001-libpq-require-encrypted-connections-for-OAUTHBEARER.patch
Description: Binary data
