On Tue, Jan 20, 2026 at 1:14 PM Zsolt Parragi <[email protected]> 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
