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