On Wed, Sep 21, 2022 at 3:10 PM Andrey Chudnovskiy <andrey.chudnovs...@microsoft.com> wrote: > We can support both passing the token from an upstream client and libpq > implementing OAUTH2 protocol to obtaining one.
Right, I agree that we could potentially do both. > Libpq passing toked directly from an upstream client is useful in other > scenarios: > 1. Enterprise clients, built with .Net / Java and using provider-specific > authentication libraries, like MSAL for AAD. Those can also support more > advance provider-specific token acquisition flows. > 2. Resource-tight (like IoT) clients. Those can be compiled without optional > libpq flag not including the iddawc or other dependency. What I don't understand is how the OAUTHBEARER mechanism helps you in this case. You're short-circuiting the negotiation where the server tells the client what provider to use and what scopes to request, and instead you're saying "here's a secret string, just take it and validate it with magic." I realize the ability to pass an opaque token may be useful, but from the server's perspective, I don't see what differentiates it from the password auth method plus a custom authenticator plugin. Why pay for the additional complexity of OAUTHBEARER if you're not going to use it? --Jacob
