> The most concrete example I can see is with the OAUTHBEARER error > response. If you want to eventually handle differing scopes per role, > or different error statuses (which the proof-of-concept currently > hardcodes as `invalid_token`), then the client can't assume it knows > what the server is going to say there. I think that's true even if you > control both sides and are hardcoding the provider.
Ok, I see the point. It's related to the topic of communication between libpq and the upstream client. > How should we communicate those pieces to a custom client when it's > passing a token directly? The easiest way I can see is for the custom > client to speak the OAUTHBEARER protocol directly (e.g. SASL plugin). > If you had to parse the libpq error message, I don't think that'd be > particularly maintainable. I agree that parsing the message is not a sustainable way. Could you provide more details on the SASL plugin approach you propose? Specifically, is this basically a set of extension hooks for the client side? With the need for the client to be compiled with the plugins based on the set of providers it needs. > Well... I don't quite understand why we'd go to the trouble of > providing a provider-agnostic communication solution only to have > everyone write their own provider-specific client support. Unless > you're saying Microsoft would provide an officially blessed plugin for > the *server* side only, and Google would provide one of their own, and > so on. Yes, via extensions. Identity providers can open source extensions to use their auth services outside of first party PaaS offerings. For 3rd party Postgres PaaS or on premise deployments. > The server side authorization is the only place where I think it makes > sense to specialize by default. libpq should remain agnostic, with the > understanding that we'll need to make hard decisions when a major > provider decides not to follow a spec. Completely agree with agnostic libpq. Though needs validation with several major providers to know if this is possible. > Specifically it delivers that message to an end user. If you want a > generic machine client to be able to use that, then we'll need to talk > about how. Yes, that's what needs to be decided. In both Device code and Authorization code scenarios, libpq and the client would need to exchange a couple of pieces of metadata. Plus, after success, the client should be able to access a refresh token for further use. Can we implement a generic protocol like for this between libpq and the clients?