This is very likely insecure. A malicious web site could replay your Auth flow to another website where you have an account that uses the same keypair.
right, would be better for the site to encrypt a one-time-use password with the public key you've, then all you have to do is decrypt it and log in, proving you possess the private key
does this have a name? always seemed like the obvious way to do it but I've never implemented auth
edit: I guess this is similar to a challenge/sign/verify signature scheme like webauthen, but is it inferior in some way?
Yep, what you've described is pretty close to the scheme in WebAuthn. The main additions in WebAuthn are for protocol level security: there's an attestation nonce, a shared counter, and some other fiddly bits to make it harder/impossible to misuse.
This is exactly what I use for an emailless password reset. Instead of sending a reset token via email, it's just encrypted with public key and user can decrypt token for reset password. There for I don't require to collect email address for account. Of course this could also be used as login method. On the downside, for UX purposes decryption can run in browser by passing private key. I have mixed feelings about pasting PKs into browser.
Yeah, there's no verification of a server's pubkey like ssh (which mostly is trust-on-first use), or a cert chain like tls.
This seems like a cool proof-of-concept. There are also a bunch of security properties that it fails in.
does this have a name? always seemed like the obvious way to do it but I've never implemented auth
edit: I guess this is similar to a challenge/sign/verify signature scheme like webauthen, but is it inferior in some way?