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

> 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.

It just says that:

> Once you enter the code displayed on your app or device, it will have access to your account.
> Do not enter codes from sources you don't trust.

And that's all. And not loudly, this isn't written with a big font
size with a warning sign or anything like that, it's just quietly
mentioned.
After that, in the next step it confirms the application name.

> 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.

Actually it's quite similar to what Azure does, Google also doesn't
display anything at all, even if I request email/profile scopes, it
just says that I'm trying to log in to application "X". It doesn't
mention scopes at all.

And regarding your previous email/attack scenario:

> then all I have to do to
> steal your credentials and log into Postgres with your identity is to
> stand up my own public web application server, for some ostensibly
> benign purpose, and add Log in with Google to that service

I just realized that this won't work - not with Google, and not with
other providers.

In the case of Google, a client id is either for a web application or
a limited device, it can't be both. A client id used for a limited
device like postgres can't be used for a web based login flow, it will
result in an error.
So if somebody wants to do this attack, they have to do something
similar to the last link with Microsoft, or create a malicious oauth
application that people for some reason will trust.

And with other providers like Azure, you can limit the redirect URL
for the web login flow. If somebody tries to use a postgres client id
with their own redirect endpoint, that won't work.

On Wed, Sep 10, 2025 at 10:47 PM Jacob Champion
<jacob(dot)champion(at)enterprisedb(dot)com> wrote:
>
> 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://url.avanan.click/v2/r01/___https://arstechnica.com/information-technology/2025/02/russian-spies-use-device-code-phishing-to-hijack-microsoft-accounts/___.YXAzOnBlcmNvbmE6YTpnOmUzZGVhNDI4OThiNzQzNzY5NmE0Njk0Mzc5Y2ZjNjA2Ojc6NTcxNDozMjZjZmZmODdhNmE0ZDkwYTUxNTZlNDk4NmFmZjU0OTYzMDdiMDc1NDQ3ZTNmMmE5MWNiMDI3YTIwMmM0NzI1OnA6VDpO
> :
>
> > 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