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-27T17:36:11Z
Lists: pgsql-hackers 
On Mon, Jan 26, 2026 at 4:06 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> Wouldn't it be simpler to do all that validation at the server side,
> and for libpq to simply compare that what the user specified for the
> connection and what the server sent are the same?

No, I don't think so. That opens up the possibility of a third-party
server implementation breaking the OAUTHBEARER rules and libpq failing
to call them out on it.

> My question should have been: shouldn't the plugin api work at the
> SASL level instead of a specific OAuth level?

IMO, yes, but I don't imagine that most people want to pick a SASL
plugin to switch OAuth flows. They just want their flow to match the
use case and move on.

> Or even if the first
> iteration of the internal API would only allow it to modify the OAuth
> flow, shouldn't the public facing configuration (env var / connection
> string / anything) be something more generic?

I think these are two different use cases that _could_ be handled with
the same knob but probably _should_ not be (see above).

> How, and when would I use this (oauth limited, differently configured)
> plugin API instead of the authdata hook? And I can't think of any good
> use cases outside the command line tools included with postgres.

That's exactly the use case. (Also, library clients of postgres that
should not install application hooks, other monolithic utilities that
link against libpq, etc.) Who wants to recompile their clients just to
switch how they get a token?

--Jacob

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