Custom oauth validator options

Sorry for missing this thread!

On Tue, Dec 2, 2025 at 5:06 AM Zsolt Parragi <zsolt.parragi@percona.com> 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]/messages/by-id/0e0c038ab962c3f6dab00934fe5ae1ae115f44c0.camel@vmware.com, and in the context of SNI's proposed pg_hosts config
[2]: /messages/by-id/CAOYmi+=ZjGJLw8tCkzY88acd=ir1r8eAxO-+5wXm9gtCUV97Sg@mail.gmail.com

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]: /messages/by-id/0e0c038ab962c3f6dab00934fe5ae1ae115f44c0.camel@vmware.com
[2]: /messages/by-id/CAOYmi+=ZjGJLw8tCkzY88acd=ir1r8eAxO-+5wXm9gtCUV97Sg@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.

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.

One issue we have is that some providers don't allow users to select
what goes into the subject claim, but do allow users to define custom
claims. Additionally, the subject claim is sometimes a random
generated id, which gets generated on the first login to the client,
and that makes it practically unusable for pg. It would require:

* user trying to login to pg
* getting rejected
* figuring out what's the subject
* adding it to pg ident / some other config
* user can finally login

Instead we decided to let everyone configure which claim they want to
use for user mapping. But because of that, this is a GUC, and they can
only configure it once pre server.

The postgres-keycloak-oauth-validator is in an even worse situation,
they decided to use a long list of GUC parameters[1]https://github.com/cloudnative-pg/postgres-keycloak-oauth-validator/blob/5fceacf53c3d86fbbe18dab0341311855a89fe6a/src/kc_validator.c#L741. The main reason
is that they use an introspection endpoint for validation instead of
the JWT, so they need multiple parameters for that. Some of these GUCs
seem redundant to me, but some of them are definitely required.

They also have parameters for the client id and debugging - those are
things we are also considering adding to our validator.

(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...)

I tried to propose simple things that are relatively easy to
implement, and wouldn't change too much at once, so there's a
realistic change for this making into PG19. I'm not against having a
bigger goal, and continuing making it even better after that.

A hypothetical PGC_HBA context would seem to fit nicely between
PGC_SIGHUP and PGC_SU_BACKEND.

How would you configure that since the hba lines don't have IDs?
Should we add a "guc_name" parameter to HBA for this or something like
that? I like this idea, it would be fun to implement and see how it
works, I'm just wondering how users could use it.

[1]: https://github.com/cloudnative-pg/postgres-keycloak-oauth-validator/blob/5fceacf53c3d86fbbe18dab0341311855a89fe6a/src/kc_validator.c#L741

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

Personally I would go with either (a) or (c), and I was planning to
clean up / improve / share my (c) patch as a second attempt for this
thread, if it didn't receive any replies. I can still do that, so that
we have multiple test implementations. (b) seemed a not as nice design
to me, but maybe you find a better way to implement it than I did.

Also now I really like the idea of the PGC_HBA, if there's a way for
users to configure it without depending on line numbers or other
easy-to-change details.

On Tue, Dec 16, 2025 at 10:30 PM VASUKI M <vasukianand0119@gmail.com> wrote:

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

Thanks!

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.

I forgot to mention in my reply to Zsolt, but we've supported inline
inclusions in HBA for a few releases now. (I just frequently forget
they exist.)

pg_hba.conf:

hostssl all all 0.0.0.0/0 oauth @oauth-settings.conf

oauth-settings.conf:

issuer=https://oauth.example.org/v2
scope="openid email let-me-into-pg"
validator=example_org
map=examplemap

And for smaller annoyances, you can wrap lines with backslash continuation.

I haven't used these new features much, since I forget they exist, so
if there are usability problems in practice please say something so we
can fix it.

--Jacob

On Wed, Dec 17, 2025 at 1:28 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:

Instead we decided to let everyone configure which claim they want to
use for user mapping. But because of that, this is a GUC, and they can
only configure it once pre server.

We're getting closer; I agree that this needs to be more flexible than
it is, and I'm on board with a change, but I'm still missing the
"killer app". What's the case where a user has multiple HBA lines that
all want to use unrelated claims for authentication to one Postgres
cluster? Is this multi-tenancy, or...?

I tried to propose simple things that are relatively easy to
implement, and wouldn't change too much at once, so there's a
realistic change for this making into PG19. I'm not against having a
bigger goal, and continuing making it even better after that.

Absolutely -- that's a tried and true strategy. No objections to that.

But I also didn't want to stay silent on my longer-term goals here.
That way (hopefully), no one's surprised to find I'm lukewarm on
patches that are extremely OAuth-specific, or that don't give us a way
to improve/evolve later. The additional flexibility of OAuth should
ideally be mirrored in other auth methods when possible.

A hypothetical PGC_HBA context would seem to fit nicely between
PGC_SIGHUP and PGC_SU_BACKEND.

How would you configure that since the hba lines don't have IDs?
Should we add a "guc_name" parameter to HBA for this or something like
that? I like this idea, it would be fun to implement and see how it
works, I'm just wondering how users could use it.

I hadn't thought it through very far; my initial impression was that
we'd need some sort of additional syntax. But I keep coming back to
httpd-style configs and then I choose something else from my TODO list
to focus on. :) See also the old conversation regarding LDAP hba/ident
[1]: /messages/by-id/CAOuzzgpFpuroNRabEvB9kST_TSyS2jFicBNoXvW7G2pZFixyBw@mail.gmail.com

On Wed, Dec 17, 2025 at 1:36 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:

Personally I would go with either (a) or (c), and I was planning to
clean up / improve / share my (c) patch as a second attempt for this
thread, if it didn't receive any replies. I can still do that, so that
we have multiple test implementations.

The more the merrier!

Thanks,
--Jacob

[1]: /messages/by-id/CAOuzzgpFpuroNRabEvB9kST_TSyS2jFicBNoXvW7G2pZFixyBw@mail.gmail.com

I forgot to mention in my reply to Zsolt, but we've supported inline
inclusions in HBA for a few releases now. (I just frequently forget
they exist.)

Thanks, I didn't know about that feature, that solves half of my problem.

What's the case where a user has multiple HBA lines that
all want to use unrelated claims for authentication to one Postgres
cluster? Is this multi-tenancy, or...?

For configuring the authn matching yes, the use case is multitenancy.

But for some other variables that we didn't implement yet, this could
be useful even without multitenancy.

One thing I mentioned in the previous email is the client id
validation. A practical use case of that would be restricting which
oauth clients can login to which database. I can't use a SUSET
variable with a check restricting it to ALTER DATABASE, because
database level variables are not yet available during the oauth
validator callback. I could use a login event trigger, but that seems
like a bad hack to me.

On Thu, Dec 18, 2025 at 12:31 AM Jacob Champion <
jacob.champion@enterprisedb.com> wrote:

On Wed, Dec 17, 2025 at 1:28 AM Zsolt Parragi <zsolt.parragi@percona.com>
wrote:

Instead we decided to let everyone configure which claim they want to
use for user mapping. But because of that, this is a GUC, and they can
only configure it once pre server.

We're getting closer; I agree that this needs to be more flexible than
it is, and I'm on board with a change, but I'm still missing the
"killer app". What's the case where a user has multiple HBA lines that
all want to use unrelated claims for authentication to one Postgres
cluster? Is this multi-tenancy, or...?

Beyond multitenancy,per -HBA OAuth cases where options are needed for

safe provider migration[blue/green],per-database security policies,mixed
Human/machine authentication[JWT/Introspection] and incident-response
scenarios -all global GUCs are too coarse.

See also the old conversation regarding LDAP hba/ident

[1]

[1]
/messages/by-id/CAOuzzgpFpuroNRabEvB9kST_TSyS2jFicBNoXvW7G2pZFixyBw@mail.gmail.com

Thanks, Will go through it.

Regards,

Vasuki M
CDAC,Chennai.

Personally I would go with either (a) or (c), and I was planning to
clean up / improve / share my (c) patch as a second attempt for this
thread, if it didn't receive any replies. I can still do that, so that
we have multiple test implementations.

I attached the patch. It modifies one of the existing oauth_validator
tests to showcase how it works, but in theory it isn't dependent on
oauth. It however requires shared_preload_libraries (that is common
for all options), maybe oauth_validator_libraries could imply that?

On Thu, Dec 18, 2025 at 1:08 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:

It however requires shared_preload_libraries (that is common
for all options), maybe oauth_validator_libraries could imply that?

Haven't looked at the patch yet, but I think most people probably want
to use session_preload_libraries, not shared_preload_libraries, so
that a security update to their validator doesn't require a restart of
the cluster.

If a particular validator implementation requires shared preload, so
be it; but I don't think we want to force it. Might be more reason to
look into the GUC system?

--Jacob

Might be more reason to look into the GUC system?

I am already thinking about that, I have some ideas for a proof of
concept, but no working prototype yet. But without requiring
shared_preload_libraries, we can't do early error reporting during
postmaster startup about custom parameters. Is that okay? GUCs already
work this way, and this could be a bit safer (reporting unknown
parameters/refusing to proceed during login, when we can completely
parse all parameters), but it would be different compared to how
pg_hba is handled currently.

On Thu, Dec 18, 2025 at 10:28 AM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:

But without requiring
shared_preload_libraries, we can't do early error reporting during
postmaster startup about custom parameters. Is that okay?

I think I need to do more staring at the intersection of GUC
registration and session_preload_libraries, because my memory of the
order of operations was faulty. I won't be able to do that before the
holidays, most likely.

--Jacob

I think I need to do more staring at the intersection of GUC
registration and session_preload_libraries, because my memory of the
order of operations was faulty. I won't be able to do that before the
holidays, most likely.

Maybe I'm missing something, but why do we need
session_preload_libraries? oauth_validator_libraries is processed
earlier, it can already define sighup GUCs, it should also work with a
new level around that. I assume that if postgres gets another
authentication plugin point later, it will be executed around the same
place, during authentication, so that also shouldn't be an issue.

The question is if non-validator libraries should be able to define
PGC_HBA variables. If yes, then either

* we don't validate that all HBA variables are valid - if somebody
made a typo, we can't detect it
* we add a sighup guc with a manual whitelist
* require shared preload libraries or oauth_validator_libraries,
because those are loaded before or during authentication
* require session_preload_libraries. We proceed with authentication
even with unresolved HBA variables, but abort the connection if there
are still unknown parameters after loading session preload.

On Thu, Dec 18, 2025 at 12:29 PM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:

I think I need to do more staring at the intersection of GUC
registration and session_preload_libraries, because my memory of the
order of operations was faulty. I won't be able to do that before the
holidays, most likely.

Maybe I'm missing something, but why do we need
session_preload_libraries?

Well, how do you want "global" GUCs registered by the validator to
behave when OAuth isn't used for the connection?

The question is if non-validator libraries should be able to define
PGC_HBA variables.

I think we should try for that, yeah. Otherwise I suspect considerable
pushback on the idea of modifying the GucContext enum for something
that can only be used by OAuth.

* require session_preload_libraries. We proceed with authentication
even with unresolved HBA variables, but abort the connection if there
are still unknown parameters after loading session preload.

Of those choices, this _seems_ nicest. It'd be good to get a feel for
how it behaves in practice though.

Thanks,
--Jacob

Well, how do you want "global" GUCs registered by the validator to
behave when OAuth isn't used for the connection?

My assumption was that with session_preload we only validate the line
used for the current login, not all the lines. This way we don't have
to always include all validator/hba plugins in session_preload, for
every login.

This is what I implemented for now, but if you think it would be
better to validate every line, I can adjust that.

Of those choices, this _seems_ nicest. It'd be good to get a feel for
how it behaves in practice though.

See the attached v2, with the above comment.

Other than the above question (validate everything vs the current
line), I'm also not entirely sure if we do need PGC_HBA. It could also
work with PGC_SIGHUP + the new PGC_S_HBA value in GucSources.

On Wed, Jan 14, 2026 at 10:20 AM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:

Well, how do you want "global" GUCs registered by the validator to
behave when OAuth isn't used for the connection?

My assumption was that with session_preload we only validate the line
used for the current login, not all the lines. This way we don't have
to always include all validator/hba plugins in session_preload, for
every login.

This is what I implemented for now, but if you think it would be
better to validate every line, I can adjust that.

Let me think about that a bit, and look over your v2 approach; my
kneejerk reaction was that this is a dangerous situation to be in. I
want to know that my HBA is invalid when I reload, not later on down
the line.

But my understanding of GUCs from session_preload_libraries also had
some wishful thinking behind it. I believed that the situation today
was stricter than it actually is:

$ tail -2 data/postgresql.conf
session_preload_libraries = auto_explain
auto_explain.blahblahblah = yes

$ psql postgres
WARNING: invalid configuration parameter name
"auto_explain.blahblahblah", removing it
DETAIL: "auto_explain" is now a reserved prefix.
psql (18.0)
Type "help" for help.

And it makes sense that the postmaster is not going to somehow unload
and reload those libraries during SIGHUP, just to check GUC settings.
Hrmmm...

(If we did go in this direction, I think we might want to be
punishingly strict for the first iteration of the feature. PGC_HBA
providers should prefix their settings to avoid confusion and/or
future collisions anyway, so if we don't know what the GUC is, and its
prefix doesn't match either a validator name -- which is DBA-blessed
-- or a valid session_preload_libraries item, I'm not sure we should
even wait to complain.)

Of those choices, this _seems_ nicest. It'd be good to get a feel for
how it behaves in practice though.

See the attached v2, with the above comment.

Thank you!

Other than the above question (validate everything vs the current
line), I'm also not entirely sure if we do need PGC_HBA. It could also
work with PGC_SIGHUP + the new PGC_S_HBA value in GucSources.

I might be misunderstanding, but wouldn't that imply that DBAs could
now put every existing SIGHUP setting into HBA? That doesn't seem
good. My hope was that some existing SIGHUP variables could be
downgraded to HBA variables (say, gss_accept_delegation or
authentication_timeout -- though there might be a chicken-and-egg
issue for the latter?), but that's going to be a short list.

--Jacob

Let me think about that a bit, and look over your v2 approach; my
kneejerk reaction was that this is a dangerous situation to be in. I
want to know that my HBA is invalid when I reload, not later on down
the line.

Yes, I see that concern, but that's a bit trickier. To do that
properly we have to validate the variables, including their values,
not just their names. If we only validate the names, that doesn't
guarantee anything.

And it makes sense that the postmaster is not going to somehow unload
and reload those libraries during SIGHUP, just to check GUC settings.
Hrmmm...

Would it be a good idea for it to dlopen/dlclose libraries? The
requirements of dlclose are not that strict, I'm not sure if it could
cause any issues. Opening a quick background process to verify it
seems safer, but even then, it could only verify the libraries
mentioned directly in the configuration.

I could write the code that does this for pg_hba on startup/reload,
but the tricky part is that we have to document that properly, to make
sure that the extensions also expects and handles the situation
correctly (that we try to validate gucs for all hba lines). Or start
one background process per hba line...

I might be misunderstanding, but wouldn't that imply that DBAs could
now put every existing SIGHUP setting into HBA? That doesn't seem
good.

Yes, that would mean that. I'm not saying that would be
better/semantically correct, but technically it could also work,
that's why I mentioned it. The main use of PGC_HBA in this patch is to
add additional error reporting / separate what can be placed into
pg_hba. I could argue both for this approach and the opposite where we
allow other variables in pg_hba.

On Fri, Jan 16, 2026 at 12:31 AM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:

Yes, I see that concern, but that's a bit trickier. To do that
properly we have to validate the variables, including their values,
not just their names. If we only validate the names, that doesn't
guarantee anything.

Right. This goes back to your question upthread as to why I brought
session_preload_libraries into all this -- I thought
session_preload_libraries already had handling for this, but it
doesn't.

Would it be a good idea for it to dlopen/dlclose libraries?

No, unfortunately.

The
requirements of dlclose are not that strict, I'm not sure if it could
cause any issues.

Last I knew (which was a while back), unloading a shared library tree
is fraught with peril, especially when you add dependency diamonds and
static initializers. I seem to remember that Windows, C++, and OpenSSL
all have particular areas of pain. My guess is that people are going
to make mistakes, leave dangling references around, and then either
crash the postmaster or (worse) copy a crashable address space into
every new backend.

And that's before you get into hooks and GUCs and etc. We used to have
a _PG_fini() callback for modules. It was disabled a long time ago
[1]: https://postgr.es/c/602a9ef5a7c60151e10293ae3c4bb3fbb0132d03

I might be misunderstanding, but wouldn't that imply that DBAs could
now put every existing SIGHUP setting into HBA? That doesn't seem
good.

Yes, that would mean that. I'm not saying that would be
better/semantically correct, but technically it could also work,
that's why I mentioned it.

Okay, but that wouldn't be a committable change.

The main use of PGC_HBA in this patch is to
add additional error reporting / separate what can be placed into
pg_hba. I could argue both for this approach and the opposite where we
allow other variables in pg_hba.

Not sure what you mean by this (maybe once I can really test the
patch, I'll see?), but the reason I suggested placing PGC_HBA right
after PGC_SIGHUP is this: any SU_BACKEND or below variable seems
logically appropriate to set per HBA line, if the DBA wants (they're
all per-session), and anything SIGHUP or above is inappropriate/unsafe
(they're per-cluster). Does your patch disable the former?

[checks] Ah, it does prohibit those. Why?

--Jacob

[1]: https://postgr.es/c/602a9ef5a7c60151e10293ae3c4bb3fbb0132d03

Last I knew (which was a while back),

Yes, I didn't want to say anything for sure, but I have similar
memories on Windows a while ago. I don't know anything for sure about
today, and especially on Linux, but delegating things to another
process seems to be a safer approach to me.

[checks] Ah, it does prohibit those. Why?

Mainly because I couldn't decide where it should fit if the variable
is set at multiple places (or if we need multiple sources like
PGC_S_DATABASE_USER).

* A hba line can be completely generic, which should be above DATABASE
(ALTER DATABASE setting should override HBA setting, as it is more
specific)
* Or very specific about one user in one database using a specific
authentication method, which should be below DATABASE_USER as it is
more specific. (hba setting should override ALTER USER ... IN DATABASE
setting)

The first choice seems more logical to me, as that's how pg_hba is
usually used, but I thought this could still be confusing.