> On 18 Jun 2026, at 06:54, Zsolt Parragi <[email protected]> wrote:
> I added another patch which is only a documentation improvement,
> that's the new 0001. The documentation is very clear about "password"
> being insecure over plaintext connections, but there's no such mention
> for oauth.
I cam absolutely get behind an improvement of the docs for master through 18
for this, ideally in time for the next minors. The attached .txt
(intentionally not a .diff or .patch since I didn't re-send your full patchset)
massages your 0001 to make it more consistent with the rest of the
documentation.
> 0002 and 0003 are the previous patches unchanged.
I am intrerested in raising the security model for postgres connections, but as
mentioned here and elsewhere it does require careful study of common container
environments like Kubernetes which may be impacted. For v19 I don't see it as
a realistic change (and I think it was too late even when initially raised,
even though it was a lot earlier in the cycle than now), but hopefully we can
raise the bar in v20.
--
Daniel Gustafsson
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
index e4e65f8feb1..873ddd8f068 100644
--- a/doc/src/sgml/client-auth.sgml
+++ b/doc/src/sgml/client-auth.sgml
@@ -652,7 +652,9 @@ include_dir <replaceable>directory</replaceable>
<listitem>
<para>
Authorize and optionally authenticate using a third-party OAuth 2.0
- identity provider. See <xref linkend="auth-oauth"/> for details.
+ identity provider. Since the bearer token is sent in clear text over
+ the network, this should not be used on untrusted networks. See
+ <xref linkend="auth-oauth"/> for details.
</para>
</listitem>
</varlistentry>
@@ -2341,7 +2343,9 @@ host ... ldap ldapbasedn="dc=example,dc=net"
<ulink url="https://datatracker.ietf.org/doc/html/rfc6750";>RFC
6750</ulink>,
which are a type of access token used with OAuth 2.0 where the token is an
opaque string. The format of the access token is implementation specific
- and is chosen by each authorization server.
+ and is chosen by each authorization server. The bearer token is sent
+ in clear-text, and is vulnerable to network sniffing. For this reason
+ OAuth should only be used over SSL connections.
</para>
<para>
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 84af9372ebe..541673eb282 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2084,6 +2084,16 @@ SELCT 1/0;<!-- this typo is intentional -->
server.
</para>
+ <note>
+ <para>
+ The bearer token is sent across the connection, as part of the client
+ initial response, and grants access to the database like a clear-text
+ password. On an unencrypted connection it can be captured by network
+ sniffing. For this reason <literal>OAUTHBEARER</literal> should only be
+ used over SSL connections.
+ </para>
+ </note>
+
<para>
<literal>OAUTHBEARER</literal> does not support channel binding, and there
is no "OAUTHBEARER-PLUS" mechanism. This mechanism does not make use of
