WebAuthn/FIDO2/U2F passkey support

[britbennett]

feat: Add WebAuthn/FIDO2/U2F passkey support

Hi @Eugeny, I have a working implementation for WebAuthn. It's a bit of a big boy so starting here, no offense taken if you don't want it (sorry, it was awkward to try to piecemeal it). If you're interested or want to know more let me know how you would like me to proceed (PR to v0.27, new branch, etc).

The primary focus is hardware key 2FA (FIDO2/U2F keys as a second factor alongside passwords), but the implementation fully supports passkeys (platform authenticators like Touch ID, Windows Hello, iCloud Keychain) as well. Passkeys could theoretically serve as a password replacement (single-factor bio passwordless login), but that would require a broader decision about refactoring the login flow — see "Not included" below.

Not included:

Note: This PR adds WebAuthn support for Warpgate's web/browser login only. It does not address SSH -sk key types (ecdsa-sk/ed25519-sk) requested in #221 — that is a separate SSH-protocol concern. However, for non-browser protocols that support web approval (SSH, PostgreSQL), this PR integrates with the existing web approval flow so users can satisfy a WebAuthn policy requirement by touching their key in the browser approval page.

Suggested UX improvement (out of scope but would add after initial PR).

• Passkey instead of password: For a non-2FA, passkey only auth policy example (passkey substituting a password) the login UI forces a password. You can type an incorrect password to get past this and then submit passkey in next continue login. Perhaps initial login only takes username/ID then a password type authentication would be extracted into the continue login flow. This way a passkey instead of password could work.

• Forced enrollment on first login: When an admin sets a passkey requirement before the user has registered one, the user is currently locked out. A "grace period" flow — where the first login succeeds with password only but forces the user to register a passkey before accessing any targets — would enable admins to enforce passkey requirements from day one without coordination. This would benefit all credential types (OTP, passkey, etc.) and is a separate feature.

Bug fix (out of scope but would add after initial PR).

• Pre-existing bug identified (follow-up PR): When the last credential of a given type is deleted (e.g. the only OTP device, the only passkey), the auth policy editor's toggle disappears but the policy value still contains the credential kind. Clicking "Update" saves a policy requiring a credential the user can't satisfy, locking them out. This affects all credential types and is a broader fix that should be addressed separately to avoid conflating concerns.

[Eugeny]

Yes - I'm very interested! Please make a PR - but it might take me at the very least until the next week to review it.

[britbennett]

Awesome! Shipped - #2360