Horton
Menu

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

Jacob Champion <jacob.champion@enterprisedb.com>

View thread
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Chao Li <li.evan.chao@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2026-01-24T01:02:09Z
Lists: pgsql-hackers 
On Tue, Jan 20, 2026 at 1:14 PM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> If it's validated on the server, and the issuer matches, that should
> be enough?

It's client-side protection against a malicious server; server-side
validation doesn't help. This is why you have to specify an issuer in
your client's connection string (my original patchset just trusted
whatever the server sent, which would have caused serious problems).
See [1] for a longer discussion.

If I've misunderstood what you mean, please tell me what function call
in particular you think can be removed.

> I don't think LDAP, or anything else is similarly extensible both on
> the server and client side?

Any plaintext password method (like LDAP) can tunnel arbitrary data,
just like a Bearer token can. So if you control both sides, you can do
whatever you want.

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

I'm very much on board with pluggable auth [2], but OAUTHBEARER is not
the layer for arbitrary non-OAuth authentication systems, any more
than LDAP is. (SASL is the correct layer for that, IMHO.)

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

Mm. I'll try to take a closer look at GitHub and Cirrus.

Thanks,
--Jacob

[1] https://postgr.es/m/CAOYmi%2BkLTJ1wZ6gxRbgtR52E%3DEyiCpmp6J3mmSvtc1a6i7sZ3Q%40mail.gmail.com
[2] https://postgr.es/m/3d41067ed944e9ce889fc15a6593cb26e72b6c0f.camel%40vmware.com

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