Re: OAuth client code doesn't work with Google OAuth

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