Horton
Menu

Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)

Zsolt Parragi <zsolt.parragi@percona.com>

View thread
From: Zsolt Parragi <zsolt.parragi@percona.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Chao Li <li.evan.chao@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2026-01-20T21:13:53Z
Lists: pgsql-hackers 
> Hopefully you mean reloads, or else there's a bad bug somewhere

Yes, reloads - I usually do restarts with local testing, but it works
with reloads.

> I'm assuming you're talking about issuer_from_well_known_uri()? That's a security gate, not just a syntax validation.

> As for the usability request to validate syntax in the server, I agree that would be good. I think that came up during v18 development...

If it's validated on the server, and the issuer matches, that should
be enough? I'm not saying that we don't match the URL at all, that
part is still needed. When I first tried out the OIDC support I even
hoped that maybe this could be used to select the hba line if we have
multiple issuers.

> Well, SASLBEARER isn't a SASL mechanism.

Oops, that's what I get for accepting the ai summary from google
without verifying properly, I should have done that before sending the
previous email.

> I can't really stop anyone from tunneling magic junk through Bearer tokens, or LDAP passwords, or anything else opaque.

> And the architecture changes for OAuth introduced enough of the bones of pluggable auth that a particular SASL mechanism shouldn't *have* to be abused in this way, if what people really want is pluggable auth.

I don't think LDAP, or anything else is similarly extensible both on
the server and client side? And most of the time, oauth
implementations in other software also aren't this extensible, so they
are more strictly tied to oauth.

And my question was exactly because of this: OAuth introduced mostly
everything needed for pluggable authentication (without PAM - my
previous experience with that is that it is system specific, slow, and
complex), and it is already possible to misuse it for something else.
It would be really nice to have a generic authentication plugin system
in postgres to implement other authentication methods, not just OAuth.

> Are they asking for this because it'd be an easy way around the v18 flow limitation? Because that's been the primary motivation in the conversations I've had.

One specific use case I know of is CI, for example GitHub simply
provides you an oauth token as an environment variable.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. libpq: Allow developers to reimplement libpq-oauth

  2. libpq: Poison the v2 part of a v1 Bearer request

  3. libpq-oauth: Never link against libpq's encoding functions

  4. libpq-oauth: Use the PGoauthBearerRequestV2 API

  5. libpq: Introduce PQAUTHDATA_OAUTH_BEARER_TOKEN_V2

  6. libpq: Add PQgetThreadLock() to mirror PQregisterThreadLock()

  7. oauth: Report cleanup errors as warnings on stderr

  8. oauth_validator: Avoid races in log_check()

  9. libpq-oauth: use correct c_args in meson.build

  10. libpq-fe.h: Don't claim SOCKTYPE in the global namespace