public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jacob Champion <[email protected]>
To: Zsolt Parragi <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Custom oauth validator options
Date: Tue, 16 Dec 2025 15:09:51 -0800
Message-ID: <CAOYmi+kvDACPXX_p2fF7+3CXza=VjjPTn2UDjd2dMAsgP6S53w@mail.gmail.com> (raw)
In-Reply-To: <CAN4CZFM3b8u5uNNNsY6XCya257u+Dofms3su9f11iMCxvCacag@mail.gmail.com>
References: <CAN4CZFM3b8u5uNNNsY6XCya257u+Dofms3su9f11iMCxvCacag@mail.gmail.com>
Sorry for missing this thread!
On Tue, Dec 2, 2025 at 5:06 AM Zsolt Parragi <[email protected]> wrote:
> 1. Configuration for OAuth validation ends up split across two
> locations: issuer/scope and a few other parameters are defined in
> pg_hba.conf, while custom parameters must be set in postgresql.conf.
Yeah. (This has come up before a couple of times that I know of, in
the context of pg_hba and pg_ident splitting important configuration
between them [1], and in the context of SNI's proposed pg_hosts config
[2].)
> 2. We have received multiple questions asking how to configure
> multiple OIDC servers with different parameter sets. I am not sure how
> common it is to use multiple OAuth providers with a single PostgreSQL
> instance, but the question is certainly reasonable.
What kinds of parameters? Having a motivating use case would be
helpful; HBA isn't always as flexible as people assume and I want to
make sure that we can end with a usable feature.
> Given this, I would like to ask what you think about making
> pg_hba.conf extensible.
Your proposals (and the concerns they raise) seem reasonable enough at
first glance. (I still want a motivating use case, though.)
Honestly, I'd *prefer* that any solution not be OAuth-specific. I
might throw two alternatives onto the pile:
d. Have HBA plug into the GUC system itself
A hypothetical PGC_HBA context would seem to fit nicely between
PGC_SIGHUP and PGC_SU_BACKEND.
e. Subsume HBA, ident, (hosts,) etc. under postgresql.conf
This is my personal white whale. I think pg_hba+ident is no longer fit
for purpose. It makes nonexistent use cases easy and common use cases
unnecessarily difficult. Most people ignore half the columns. New
users are surprised that you can't choose between authentication
options. You have to correlate a bunch of different files with
differing syntaxes to figure out what is going on. Etc, etc.
This is why I bypassed pg_ident for validators, so that they could be
free to do useful stuff while the core caught up. But I didn't intend
to keep them separate forever.
(I'm only halfway serious with (e) -- I don't really intend to drive
your thread straight into a wall. But when I read proposals a-c, I get
the sinking feeling that this *should* be solved in a more radical
way, if we could only agree on a direction...)
Thanks,
--Jacob
[1] https://postgr.es/m/0e0c038ab962c3f6dab00934fe5ae1ae115f44c0.camel%40vmware.com
[2] https://postgr.es/m/CAOYmi%2B%3DZjGJLw8tCkzY88acd%3Dir1r8eAxO-%2B5wXm9gtCUV97Sg%40mail.gmail.com
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]
Subject: Re: Custom oauth validator options
In-Reply-To: <CAOYmi+kvDACPXX_p2fF7+3CXza=VjjPTn2UDjd2dMAsgP6S53w@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