If you need to enter your credentials when using sign-in-using-xxx, be VERY cautious. Even if you have 2FA enabled, the fake oauth screen can just ask you for the 2FA code. You have no way of knowing whether the login page is keylogged or hijacked.
Something I still don't understand about the OAuth flow is how it's _not_ training users to be more easily phished for actual usernames and passwords. The very first step is "If you are not logged into the third-party, display a login-form from the third-party."
The thing is, you never really know off-hand if you're logged into the third-party (provider) or not without opening a second tab and going directly to the third-party's site, since you're always getting logged out after various timeouts, cookie-clearing, browser-closing, and computer-restarting events.
What prevents an OAuth client application from displaying an OAuth process that shows a fake login form, which looks identical to the provider's login form, to get the user to enter their provider username and password before they realize the URL is off? It seems like it trains users that it's normal for websites to launch a Gmail login form and this is perfectly safe.
This [1] says "In fact, the spec requires that browsers only expose the API in secure contexts", so if that's correct it's better, but still not good enough.
This [2] looks like it does U2F by grabbing the challenges via browser plugin and relaying them to a phone app for signing.
Trusting the browser to "expose the API in secure contexts" seems like a failure because it's assuming nothing else can collect the credentials or send a challenge to a security key. Is that true? Could I write an app that would phish a user into signing a challenge with their security key?
What sort of app? A full-blown Windows/ OS X/ Linux desktop application? Yes.
You definitely should not install software that asks you to interact with your FIDO authenticator in this way unless you really trust it. I trust the Operating System vendor installed OpenSSH packages, I would not trust some random github project.
The two big phone ecosystems won't let you talk directly to a third party authenticator or to their built-in platform authenticator. The authenticator talks to them, and they talk to you. So while it would be possible to make a Windows EXE program that says "Touch authenticator to stroke your 3D pet" or whatever and actually steals your Facebook login credential this way, it should not be possible to put something on Google Play or Apple's iPhone store that does the same thing.
Edited to add: For Android at least there is a concept of "Privileged" apps that get to do stuff that is otherwise impossible to ask a user for permission to do. The ability to fill out WebAuthn-style rpId values (for WebAuthn these are Internet FQDNs) is locked behind such a privilege. So, Chrome has privilege, release builds of Firefox have privilege, and so on, but yet another fly-by-night app developer who uploads Flappy Bird clones to the Play Store can't use this feature.
Without this privilege when you talk to the authenticator (either a platform authenticator or a 3rd party one) the OS will insist on picking an rpId with a platform specific prefix. So e.g. maybe your app can ask for rpId android-584fac03:google.com but there's no way (without privilege) to get just google.com, which is a problem because that's the value you'd need in order to get working Google credentials.
If you want your app to talk to your own web site, you can build a bunch of extra goops (in Android at least) to enable that, but part of what will happen is your web site's backend code needs to explicitly go "OK, I should allow android-584fac03:my-private-app even though that's nowhere close to my actual FQDN" so that seems safe enough.
Not all 2FA is “enter a code”; it's a lot harder for a fake oauth screen to send a request to your registered authentication device.
EDIT: this doesn't really help, as a reply points out. OTOH, separate side channel verification of logon from unexpected devices does.
But now that I think about it, it would make sense to combine new device notification with push-notice 2FA for exactly that reason, since you've got a push channel that takes a confirmation already, flag unexpected devices in that channel as well and it becomes much more secure.
An attacker can play the legitimate WebAuthn request from the real site, which will (statistically certain) be nonsense if played by their phishing site.
Or they make their own request, which doesn't help them because it's not valid on the real site they want to sign into so it's pointless.