They want the power to add arbitrary extra steps in the login flow.

For example, maybe they want to force the user to change a compromised password, or hand over their phone number, or complete a captcha, or accept a load of legalese.

You can do this without a webview in your application, but it usually means giving the user an URL to open in their own browser.

Doesn't google explicitly forbid a WebView for oauth?

The point is to not have users entering their google credentials into third-party apps, and a WebView is still entering your credentials into a third-party app. The app has to open the google login page in a real browser, not a WebView.

Oh, I see. BTW don't hardware keys (e.g. Yubikey) solve that problem entirely?

No.

Hardware keys are a second factor. But if you allow passwords to be compromised just because there is a second factor, then you're back down to one-factor auth and you've solved nothing

Fido keys can also be used without password or even an account name (but with pin which becomes the second factor in that scenario). They are very resistant to phishing because they do a challenge response every time that's bound to the domain name of the requesting site. So typosquatting tricks won't work. The private key is generated and stored in the token and they are very resistant to extraction.

In general it's way safer than a password that can be intercepted and reused by anyone who knows it.

but we're talking about google's implementation here, where fido keys are only a second factor. and in google's implementation, allowing passwords to be compromised means compromising your security, because their authentication flow is based around having more than just one factor.

Well. Hardware keys are just hardware keys. They can be used as a second factor, they can be used as a third factor, they can be used as the only factor. It's not immediately obvious that using only a password is less secure than using only a hardware key.

Don't passkey's just use the hardware key as the only factor (or at least that's how I've seen it implemented)?

I would say that if you use your fingerprint to unlock the hardware key on your smartphone, then you have two factors: one needs to both steal your smartphone (for the hardware key) and copy your fingerprint.

Or am I missing something here?

Passkey's don't strictly require 2FA sources.

Some hardware keys like yubikey's generally only prove physical presence of the key. And software implementations exist too.

> Why does it require a WebView, btw?

So you can't read your mail from a platform that doesn't have a web browser installed...

Edit: to be more clear: so you can't read your mail from a platform that can't run or embed a modern web browser. For example... a command line only system without a GUI.

Sure you can, you just have to complete the OAuth2 login on a different device (e.g. phone) and then forward the token to the device which has no web browser.

On the phone itself the WebView limitation is worked around via deep linking (start Browser from App and once logged in start App from Browser with token).

There are tons of different ways how to do this actively being used.

App passwords still work. There's no need to be hyperbolic.

... for how long?

I suppose it technically doesn't require a WebViee, but that's the easiest solution in most cases.

I'm not sure how you're going to implement Google's 2FA in a non-WebView solution, but if you can get the right UI and data flows to work, I'm sure you can do without.