Re: [oauth] Stabilize the libpq-oauth ABI (and allow alternative implementations?)

> If I've misunderstood what you mean, please tell me what function call
> in particular you think can be removed.

I meant that it calls issuer_from_well_known_uri, and does multiple
validation steps in that.

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?

The protection would still be there, as the client still compares the
URLs, but the validation moves to the server, where we can detect
incorrect URLs earlier.

> So if you control both sides, you can do whatever you want.

Yes, but I can't start postgres with a custom LDAP backend or client
library, or at least not in an easy built in way.

> 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.)

That part is understandable - I mistakenly thought that there's a
generalized OAUTHBEARER mechanism in SASL, but there isn't.

And from your original email,

> I just don't know that this envvar approach is any good.
> ...
> At which point we'll have essentially designed a generic libpq plugin system.

My question should have been: shouldn't the plugin api work at the
SASL level instead of a specific OAuth level? 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?
The connection string approach would definitely be better, but not
naming the environment variable OAUTHSOMETHING would already make this
a more future-proof feature. If you think generic extensibility should
work with SASL, I see that as one more reason why the variable should
be named SASLsomething instead.

In my previous email I didn't reply to the plugin/configuration part
of your message because I wanted to think more about the question.
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. But
if it's the beginning of a generic API that gets extended in later
major versions, that's different.