From: Daniel Gustafsson <dgustafsson@postgresql.org>
Date: Fri, 5 Jun 2026 22:18:30 +0000 (+0200)
Subject: doc: Clarify OAuth validator authn_id logging
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4cb2e2fe0aa8251bef8c2e2351cd5a062c105c0a;p=thirdparty%2Fpostgresql.git

doc: Clarify OAuth validator authn_id logging

Document that OAuth validators can return an authenticated identity
in the authn_id member.  The server records the identity value before
checking if the connection is authorized, so it may appear in
connection-authentication logs (even if the connection later fails
authorization).

Also remove outdated wording saying that all result parameters are
ignored when a validator returns false since validators may provide
error_detail.

Patch by Chao Li with some additional wordsmithing by me.

Author: Chao Li <lic@highgo.com>
Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com>
Reported-by: Daniel Gustafsson <daniel@yesql.se>
Discussion: https://postgr.es/m/0281836A-F5FF-41A5-9EE1-656C1FAAC6B2@gmail.com
---

diff --git a/doc/src/sgml/oauth-validators.sgml b/doc/src/sgml/oauth-validators.sgml
index 8aad470a464..d69b6cf98ad 100644
--- a/doc/src/sgml/oauth-validators.sgml
+++ b/doc/src/sgml/oauth-validators.sgml
@@ -395,13 +395,18 @@ typedef struct ValidatorModuleResult
     token) shall be palloc'd and returned in the <structfield>result->authn_id</structfield>
     field.  Alternatively, <structfield>result->authn_id</structfield> may be set to
     NULL if the token is valid but the associated user identity cannot be
-    determined.
+    determined.  If the validator returns <literal>true</literal> and
+    set <structfield>result->authn_id</structfield> then the identity appears
+    in the server log when <xref linkend="guc-log-connections"/> includes
+    <literal>authentication</literal>.  This happens before authorization and
+    will log authentication even if the connection is later rejected due to
+    authorization.
    </para>
    <para>
     A validator may return <literal>false</literal> to signal an internal error,
-    in which case any result parameters are ignored and the connection fails.
-    Otherwise the validator should return <literal>true</literal> to indicate
-    that it has processed the token and made an authorization decision.
+    in which case the connection fails.  Otherwise the validator should return
+    <literal>true</literal> to indicate that it has processed the token and made
+    an authorization decision.
    </para>
    <para>
     In either failure case (validation error or internal error) the module may