Re: [PoC] Federated Authn/z with OAUTHBEARER

On Mon, Jan 27, 2025 at 2:50 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> + conn->allowed_sasl_mechs[0] = &pg_scram_mech;
> I'm not a huge fan of this hardcoding in fill_allowed_sasl_mechs(). It's true
> that we only have one as of this patch, but we might as well plan a little for
> the future maintainability. I took a quick stab in the attached.

Okay. I've folded that in and simplified it some, to remove the unused
names and just store the mechanism pointers without a wrapper struct;
see what you think.

> Unless there are objections I aim at committing these patches reasonably soon
> to lower the barrier for getting OAuth support committed.

Thanks!

--

v44 tackles threadsafety for older versions of Curl. If we can't prove
that the installed libcurl is threadsafe at configure time, we'll wrap
our one-time initialization in the pg_g_threadlock. Otherwise, we
won't bother with locking, but we will bail out loudly if our
threadsafety code has not been compiled in and libcurl has been
downgraded to a version/build that can't do that itself. Documentation
has been added for clients, to detail when they need to worry about
PQregisterThreadLock(), in the same way they already do with Kerberos.

While I was playing with that, I noticed that the Autoconf side of
things was not correctly picking up pkg-config variables, and my local
environment had masked the bug. I've added code to handle
CFLAGS/LDFLAGS in the same way that e.g. libxml is handled.

libpq no longer requires the authorization server to advertise support
for the device_code grant type. Entra ID doesn't appear to add that to
any of the openid-configurations it publishes, which was the primary
impetus for the change. Note that if a provider claims to support a
device_authorization_endpoint but then rejects a device_code grant,
we're not going to know what spec they're implementing anyway, so this
check likely doesn't give us any particular advantage. I've removed it
with an explanatory comment.

A description of the OAUTHBEARER handshake has been added to our
protocol docs, and I've added a comment to the new GUC in the sample
file. I've also added slightly nicer error messages in the case that
either OAuth endpoint isn't secured by HTTPS.

Thanks,
--Jacob