Right -- again, assuming the best intentions around this change and only thinking about the security implications, I'm just wondering if trying to secure that process is counterproductive in itself.

I really like the engineering concept of encouraging developers to fall into a "pit of success" and I wonder if having an alternate auth flow that genuinely avoids most of these problems beyond the very narrow "developers can access the context of the current web page" problem would be better. We really shouldn't do embedded login forms at all, we should encourage developers to move away from them.

I'd support a web standard that made it easier to use the user-controlled actual browser to handle auth requests by apps. That would at least give the user visual access to the URL which would fend off some phishing attacks. And (assuming the FIDO Alliance shapes up and actually addressed current problems with spec) passkeys would be even better for this since cross-environment authentication that doesn't transfer credentials and is invulnerable to (most) phishing is passkey's entire deal.

I don't want to make a hard claim because I don't know the research, but I would not take it as a given that a change that as a side-effect encourages developers to embed login forms is a net benefit for user security.

For most purposes, you could probably have the phone have a TLS cert for an identity, have the identity provider sign that cert, then use mTLS. No phishing possible because you're not giving access to anything; just proving your identity to whichever server you talk to (and they can't forward that proof).

Honestly I'm not sure why oauth became such a thing and mutual SSL did not. Most "social login" use cases don't need a token that grants any access to anything from the idp. Just proof of id, which could be done in the background by your browser/OS service though some standardized cert renewal process.