public inbox for [email protected]  

help / color / mirror / Atom feed

From: VASUKI M <[email protected]>
To: Zsolt Parragi <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Robert Haas <[email protected]>
Cc: [email protected]
Subject: Re: Custom oauth validator options
Date: Wed, 17 Dec 2025 12:00:44 +0530
Message-ID: <CAE2r8H55geNFtECuFunpgn0LJK2+rntGuTeqNr6mP7gGhWFRbA@mail.gmail.com> (raw)
In-Reply-To: <CAN4CZFM3b8u5uNNNsY6XCya257u+Dofms3su9f11iMCxvCacag@mail.gmail.com>
References: <CAN4CZFM3b8u5uNNNsY6XCya257u+Dofms3su9f11iMCxvCacag@mail.gmail.com>

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=...
> 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= 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’ll plan to
send a patch shortly exploring option (b).

Regards,

Vasuki M
CDAC,Chennai.

view thread (24+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Custom oauth validator options
  In-Reply-To: <CAE2r8H55geNFtECuFunpgn0LJK2+rntGuTeqNr6mP7gGhWFRbA@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox