From: Jacob Champion <jchampion@postgresql.org>
To: pgsql-committers@lists.postgresql.org
Subject: pgsql: libpq: Introduce PQAUTHDATA_OAUTH_BEARER_TOKEN_V2
Date: Fri, 06 Mar 2026 20:09:28 +0000
Message-ID: <E1vybUG-002jDK-2l@gemulon.postgresql.org> (raw)
libpq: Introduce PQAUTHDATA_OAUTH_BEARER_TOKEN_V2
For the libpq-oauth module to eventually make use of the
PGoauthBearerRequest API, it needs some additional functionality: the
derived Issuer ID for the authorization server needs to be provided, and
error messages need to be built without relying on PGconn internals.
These features seem useful for application hooks, too, so that they
don't each have to reinvent the wheel.
The original plan was for additions to PGoauthBearerRequest to be made
without a version bump to the PGauthData type. Applications would simply
check a LIBPQ_HAS_* macro at compile time to decide whether they could
use the new features. That theoretically works for applications linked
against libpq, since it's not safe to downgrade libpq from the version
you've compiled against.
We've since found that this strategy won't work for plugins, due to a
complication first noticed during the libpq-oauth module split: it's
normal for a plugin on disk to be *newer* than the libpq that's loading
it, because you might have upgraded your installation while an
application was running. (In other words, a plugin architecture causes
the compile-time and run-time dependency arrows to point in opposite
directions, so plugins won't be able to rely on the LIBPQ_HAS_* macros
to determine what APIs are available to them.)
Instead, extend the original PGoauthBearerRequest (now retroactively
referred to as "v1" in the code) with a v2 subclass-style struct. When
an application implements and accepts PQAUTHDATA_OAUTH_BEARER_TOKEN_V2,
it may safely cast the base request pointer it receives in its callbacks
to v2 in order to make use of the new functionality. libpq will query
the application for a v2 hook first, then v1 to maintain backwards
compatibility, before giving up and using the builtin flow.
Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com>
Discussion: https://postgr.es/m/CAOYmi%2BmrGg%2Bn_X2MOLgeWcj3v_M00gR8uz_D7mM8z%3DdX1JYVbg%40mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/e982331b52083ee81f5f62f9872c874cbc1862c1
Modified Files
--------------
doc/src/sgml/libpq.sgml | 84 +++++++++++++++++++
src/interfaces/libpq/fe-auth-oauth.c | 87 ++++++++++++++------
src/interfaces/libpq/libpq-fe.h | 31 ++++++-
.../modules/oauth_validator/oauth_hook_client.c | 96 +++++++++++++++++++++-
src/test/modules/oauth_validator/t/002_client.pl | 60 +++++++++++++-
src/tools/pgindent/typedefs.list | 1 +
6 files changed, 323 insertions(+), 36 deletions(-)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: jchampion@postgresql.org, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: libpq: Introduce PQAUTHDATA_OAUTH_BEARER_TOKEN_V2
In-Reply-To: <E1vybUG-002jDK-2l@gemulon.postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox