> I think this is focusing on authentication again. I mean that you need
> to authorize the _client_ -- libpq itself. What does the consent
> screen say for a user logging in, in your proposed architecture?
I tried to implement my idea, and apparently it doesn't work the way I
described it. Limited devices are restricted in what they can do, and
this information is too sensitive for them, the API doesn't allow
access to them.
What can work:
* basic oauth authentication with just the "email" scope. (consent
form only shows that application X wants to access your email address)
* for simple use cases, the validator checks the domain of the user,
and if it matches the required domain, it allows the connection
* for more complex use cases (actual permission verification within
the organization) a server side (google specific) validator account
could access the more restricted google APIs, and verify if the user
is allowed to connect or not
So this is not strictly OAuth now, but still within what can be
implemented in a validator library.
On Tue, Sep 9, 2025 at 4:13 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Tue, Sep 9, 2025 at 1:16 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> > You still can't add custom scopes to google. But in the most basic use
> > case for this if you have an organization setup, you can restrict
> > authentication to that organization. After that there still has to be
> > a postgres user, and possibly a usermap entry mapping to it.
> > There's also the customAttributes in userinfo, where an organization
> > admin can store custom information about any user, and the validator
> > logic can check this, and require specific fields / values there.
>
> I think this is focusing on authentication again. I mean that you need
> to authorize the _client_ -- libpq itself. What does the consent
> screen say for a user logging in, in your proposed architecture?
>
> > > I would personally prefer a "quirks mode" rather than a configuration
> > > knob. More specifically: the last time I looked into this, it appeared
> > > that Google required all of its Device Grant clients to go through the
> > > hardcoded issuer
> >
> > Yes, that's also how I deal with it on the validation side, I just
> > wasn't sure if adding provider specific hacks to the client is a good
> > idea, if we can make it generic that works with anything.
>
> Maybe for the authentication switch (header vs request body), but IMO,
> 428 is a definite Googleism that doesn't need to be made generic. If
> we can avoid adding knobs, then future compatibility tweaks remain
> (potentially) backportable. And I think we need to be designing for
> compatibility backports in the long term, in the same way that we
> might need to update LDAP or RADIUS or etc. from time to time.
>
> --Jacob
