3 ms·
> without creating a whole new protocol Doesn't it "just" require a CLI client that can speak both FIDO U2F and whatever the MFA provider uses? But yeah point
by fc417fc802 2y ago
> without creating a whole new protocol
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.
- linkregister 2y agoIndeed 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.
- fc417fc802 2y agoAt 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.