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

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)
Date: 2026-01-24 01:02:09
Message-ID: CAOYmi+mQeneEuoWsO1uOZszrE_tMuF51sKNzT0Z=cevpV5H3_g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 20, 2026 at 1:14 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2026-01-24 01:16:23 Re: docs: clarify ALTER TABLE behavior on partitioned tables
Previous Message David G. Johnston 2026-01-24 00:57:19 Re: docs: clarify ALTER TABLE behavior on partitioned tables