The idea of using SSO for SSH sounds interesting for some applications, but does the login process really need to be browser-based? Can't we just have the login prompt in the terminal (without needing to run a headless browser behind-the-scenes of course)? I'm often working on headless machines, and other devices that definitely don't have a browser installed, and it would be pretty painful to use (not to mention that when working in a terminal, I find very annoying to have to switch to a browser, or to any other window by the way).
All the major OpenID Provider want you to use a browser so that users aren't exposing their raw credentials like passwords to an application. We did have an experimental version of this working in a terminal for integration tests a long time ago, but Google views that as malicious behavior and tries to prevent you from doing that. It turns into an arms race with the IdPs.
The good news is you only have to login through the browser once in the morning and then you can use the generated ssh key all day long.
The browser is also an application. Of course I somehow doubt ELinks will be working with the Google auth page anytime soon.
It seems that the goal is to minimize the number of applications into which users view entering their credentials as "normal". The obvious missing piece then is some standardized FOSS project to handle CLI login.
Of course that is also unlikely to go over well since what the centralized providers actually want (which is fundamentally incompatible with user freedoms) is attestation. Arbitrarily blessing a few browser implementations that are extremely difficult to compile on your own is just a roundabout method to approximate that (IMO anyway).
Edit: It seems like a mistake to me to conflate anit-phishing efforts and IdP. Anti-phishing should be via hardware tokens or TOTP or whatever. IdP should be about large corporations managing user accounts or about individuals gaining convenience, including by serving as an adapter so that the latest popular standard can be used without each downstream service needing to adopt it.
I wrote a proprietary variation of this project for a large organization and used a similar approach to the author. The primary reason I used the browser for authentication was to take advantage of FIDO U2F (Yubikeys). Openssh does support U2F authentication, but it requires the user to sign a public key with the hardware device, forcing the organization to again store users' public keys.
The users disliked the redirects to and from the MFA provider just to log in and receive a signed SSH certificate, but there was no practical way to perform logins in the terminal without creating a whole new protocol and expanding the timeline of the project.
Doesn't it "just" require a CLI client that can speak both FIDO U2F and whatever the MFA provider uses? But yeah point taken.
Even if Google and Microsoft don't support it could a FOSS CLI client capable of speaking all the relevant protocols have resolved your issue? With OpenPubkey gaining support it seems to me that a service could potentially support exclusively that and in doing so cover all necessary auth methods simultaneously, at least assuming the provider is comfortable self hosting an IdP solution.
Indeed I would have preferred to interact with the U2F system libraries, create a challenge-response protocol for the registered U2F device to authenticate, and open source the effort. But I was not skilled enough at pitching the expanded scope. It would have been a more interesting project though!
If I take a sabbatical then writing a client like that sounds interesting. Part of it would be inventing a new MFA provider, as the existing MFA APIs don't expose a "sign with U2F device" authentication method, as far as I know.
At least pocket id and keycloak support fido2/webauthn; I'm sure there are others. I'm not sure how involved a CLI interface for that flow would be though. (Maybe someone has already done it? If so I didn't immediately come across it.)
Keycloak for example provides an API for the password flow. So webauthn via API definitely isn't too far off of what it already provides.
