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