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

On Wed, Sep 10, 2025 at 11:50 AM Zsolt Parragi
<zsolt(dot)parragi(at)percona(dot)com> wrote:
> > and the only chance
> > you'll have to reject the theft is to notice that the client name
> > looks different from usual. (If I catch you on the first login, you
> > might not even know what "usual" is.)
>
> Isn't this also true with custom scopes?

I would say "no", because the point of the consent screen is to review
the privileges that you are granting to a third party. If you're
comfortable letting a third party retrieve your email address, that's
your choice. But that third party should be not be able to upgrade an
email-scoped token to "allow access to your Postgres database" without
your express consent.

> Similarly the only thing
> protecting users if they notice that something is strange in the
> request

If a malicious service asks clearly and politely for read/write access
to all of your data, and you grant that access, an OAuth resource
server is unfortunately not at fault if it is then told to delete all
your data. (Clickthrough fatigue is a very real problem, but it's not
one I know how to unilaterally fix inside our client implementation.)

By contrast, if a malicious service asks for OpenID, and the user is
comfortable granting that, and then a validator silently upgrades the
issued token's scope and lets the malicious service do a bunch of
other non-OpenID stuff too? That validator is absolutely at fault.
OAuth systems are supposed to protect against this.

> I agree that this is a possible attack vector,

Okay, good.

> but I don't see how it
> is specific to Google,

I don't think it's specific to Google. It would apply to any provider
that doesn't let you identify a scope for your database access and
make users consent to it. But it's a validator's job to catch that
omission and fail the connection. Please do not lie to Postgres and
set ValidatorModuleResult.authorized if the client has not actually
been authorized to connect by the user.

(So -- if we become quite certain that it's impossible to implement a
client authorization step for a provider, maybe it'd be a bad idea for
me to implement a client compatibility hack for that same provider
right this instant? If nothing else, the incompatibility has already
led to valuable discussions with you and other validator authors on
the list.)

> and how it can't happen with Azure or some
> other provider which is already supported by the current code. Azure
> simply logged me in with a custom scope, without displaying the
> requested scopes at all.

That is, IMHO, its own separate problem. From
https://arstechnica.com/information-technology/2025/02/russian-spies-use-device-code-phishing-to-hijack-microsoft-accounts/
:

> The effectiveness of [Azure device code phishing] is, in large part, the result of the
> ambiguity in the user interface of the device code authorization
> process. That means it's important for people to pay close attention to
> links and the pages they lead to. Microsoft Azure prompts users to
> confirm they're signing into the app they expect. People should look for
> it and be suspicious of messages where this option is missing.

So, MS Entra does something that's kind of the reverse of the
situation I described above: it just yells at you loudly that a device
is going to "have access to your account", even if the device isn't
actually requesting access scopes, and demands that you double-check
the trustworthiness of the device. That would certainly be enough to
scare me away in the situation I described upthread, so... I guess
it's not a CVE? MS is clearly aware that their device flow does not
present a scope consent screen.

But this introduces more user fatigue, because what Entra is telling
me is _also_ a lie, and I can't see what access is actually being
requested. Which leads to the problem reported on by the Ars article
above. So I guess I just have to be hypervigilant as an Entra user.
(And what was the point of going through the custom scope
registration, if Entra won't display them in all the situations
they're being requested?)

So I don't like that, either, but it's still different from
silent-scope-upgrade via validator. The Entra problem is not something
we can catch; the Google problem is.

--Jacob