MIME-Version: 1.0
References: 
 <CAN4CZFM3b8u5uNNNsY6XCya257u+Dofms3su9f11iMCxvCacag@mail.gmail.com>
In-Reply-To: 
 <CAN4CZFM3b8u5uNNNsY6XCya257u+Dofms3su9f11iMCxvCacag@mail.gmail.com>
From: VASUKI M <vasukianand0119@gmail.com>
Date: Wed, 17 Dec 2025 12:00:44 +0530
Message-ID: 
 <CAE2r8H55geNFtECuFunpgn0LJK2+rntGuTeqNr6mP7gGhWFRbA@mail.gmail.com>
Subject: Re: Custom oauth validator options
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 jacob.champion@enterprisedb.com,
	david.g.johnston@gmail.com, Robert Haas <robertmhaas@gmail.com>,
 myon@debian.org
Content-Type: multipart/alternative; boundary="000000000000243cc806461ffbfb"
Archived-At: 
 <https://www.postgresql.org/message-id/CAE2r8H55geNFtECuFunpgn0LJK2%2BrntGuTeqNr6mP7gGhWFRbA%40mail.gmail.com>
Precedence: bulk

--000000000000243cc806461ffbfb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi All,

The core issue,as you said,is that OAuth validators can add custom
validation logic,but they can't define their own authentication-related
parameters in pg_hba.conf,where they naturally belong.Because of
that,validator-specific config ends up pushed into postgresql.conf via
GUCs,which feels a bit awkward and scattered.

That leads to the same points you mentioned:

1]OAuth configuration gets split between pg_hba.conf and
postgres.conf,which is confusing to reason about.
2]using multiple OIDC/OAuth providers with different parameter sets on a
single Postgresql instance is hard(or effectively impossible),even though
it's a pretty reasonable use case.

Given the constraints of the current HBA model(and similar issues that
recently came up with SNI),I agree that anything involving generic
extensibility or nested configuration would be a big hammer and likely too
complex.

I also have two related questions, which might be addressed as part of
> the above or independently:
>
> 1. HBA options are parsed sequentially. If validator-specific options
> are tied to a particular validator, this implies that validator=3D...
> must appear before its parameters when multiple validators are loaded,
> since we cannot otherwise determine which validator is used. Is this
> acceptable behavior, or should options be allowed in any order?
>
> 2. If a validator introduces many options, an HBA line could become
> very long and hard to read. Would it make sense to allow loading the
> parameters for a given line from a separate file? This might already
> be useful today: for example, if a long issuer URL is repeated across
> several HBA lines, it could instead be defined once in an external
> file and referenced multiple times.
>
>
So the direction I'm most aligned with is option (b): letting OAuth
validator advertise a limited list of additional valid option names for
pg_hba.conf,while keeping parsing,ordering rules,and validation firmly in
core.That seems like the least spicy option-incremental,OAuth-scoped,and
not a redesign of HBA parsing.

Reg. ordering:requiring validator=3D to appear before validator-specific
options feels acceptable to me if this is pursued,since it keeps parsing
simple and avoids ambiguity.
Reg very long HBA lines: totally agree this is a real readability issue,but
allowing per-line includes or external file feels like a seperate(and much
bigger)topic,probably best tackled independently.

Overall, +1 that this limitation is real and worth discussing.I=E2=80=99ll =
plan to
send a patch shortly exploring option (b).

Regards,

Vasuki M
CDAC,Chennai.

--000000000000243cc806461ffbfb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><p>Hi All,</p><p>The core issue,as you sa=
id,is that OAuth validators can add custom validation logic,but they can=
9;t define their own authentication-related parameters in pg_hba.conf,where=
 they naturally belong.Because of that,validator-specific config ends up pu=
shed into postgresql.conf via GUCs,which feels a bit awkward=C2=A0and scatt=
ered.</p><p>That leads to the same points you mentioned:<br><br>1]OAuth con=
figuration gets split between pg_hba.conf and postgres.conf,which is confus=
ing to reason about.<br>2]using multiple OIDC/OAuth providers with differen=
t parameter sets on a single Postgresql instance is hard(or effectively imp=
ossible),even though it&#39;s a pretty reasonable use case.<br><br>Given th=
e constraints of the current HBA model(and similar=C2=A0issues that recentl=
y came up with SNI),I agree that anything involving generic extensibility o=
r nested configuration=C2=A0would be a big hammer and likely too complex.<b=
r><br></p></div><div class=3D"gmail_quote gmail_quote_container"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">
I also have two related questions, which might be addressed as part of<br>
the above or independently:<br>
<br>
1. HBA options are parsed sequentially. If validator-specific options<br>
are tied to a particular validator, this implies that validator=3D...<br>
must appear before its parameters when multiple validators are loaded,<br>
since we cannot otherwise determine which validator is used. Is this<br>
acceptable behavior, or should options be allowed in any order?<br>
<br>
2. If a validator introduces many options, an HBA line could become<br>
very long and hard to read. Would it make sense to allow loading the<br>
parameters for a given line from a separate file? This might already<br>
be useful today: for example, if a long issuer URL is repeated across<br>
several HBA lines, it could instead be defined once in an external<br>
file and referenced multiple times.<br><br></blockquote><div><br><div dir=
=3D"ltr"><p>So the direction I&#39;m most aligned with is option (b): letti=
ng OAuth validator advertise a limited list of additional=C2=A0valid option=
 names for pg_hba.conf,while keeping parsing,ordering rules,and validation =
firmly in core.That seems like the least spicy option-incremental,OAuth-sco=
ped,and not a redesign of HBA parsing.</p><p>Reg. ordering:requiring valida=
tor=3D to appear before validator-specific options feels acceptable to me i=
f this is pursued,since it keeps parsing simple and avoids ambiguity.<br>Re=
g very long HBA lines: totally agree this is a real readability issue,but a=
llowing per-line includes or external file feels like a seperate(and much b=
igger)topic,probably best tackled independently.<br><br>Overall, +1 that th=
is limitation is real and worth discussing.I=E2=80=99ll plan to send a patc=
h shortly exploring option (b).<br><br>Regards,</p><p>Vasuki M<br>CDAC,Chen=
nai.</p></div><div class=3D"gmail_quote gmail_quote_container"><br class=3D=
"gmail-Apple-interchange-newline"></div>=C2=A0</div></div></div>

--000000000000243cc806461ffbfb--