Passkeys are a public/private keypair, where the service you're authenticating against has the public key and your browser has the private key. To authenticate, the browser demonstrates that it has the private key by signing and returning a challenge sent by the server.

So, unlike API keys, the actual passkey is never sent anywhere out of your device. Passkeys are more like SSH keys than API keys.

One difference between SSH and the WebAuthn protocol is that the challenge identifies which key it is expecting. So the user doesn't have to explicitly select which key to use.

If you are not careful, you'll enter the random chains of characters into a phishing site.

But a phishing site can't steal your passkey and forward it to the real site, the passkey will just not work with the phishing site if you try using it there, it's locked to the authentic domain.

That's mumbo jumbo to me so far.

What's an authentic domain?

How is my passkey locked to it?

The domain that the verifier (the site trying to authenticate you) is at is part of the cryptographic process. If the domain doesn't match (ie you're at a phishing site) then the results of the cryptography won't be valid for the actual correct site, only the phishing site (which gets the phishing site nothing it can use).

Passkeys are a private key stored on your device with the public key registered with the server.

Servers should allow multiple passkeys per user (so you can register multiple devices), but many don't.

X.509 already does that, and in a better way. It also makes it unnecessary to register multiple devices, if you allow certificate chains (the server would check the certificate chain; one of the was issued by the service and contains information about which account it is associated with; the other ones you can issue to yourself, optionally with more restricted permissions, and can be revoked or expire). That would also allow you to have passworded private keys, and/or to store one private key on a separate computer that is not connected to the internet to issue the other one to yourself in order to mitigate security issues (and you can revoke the certificate and make a new one if it is compromised or expires). X.509 also is not limited to only WWW, so it can be used with other protocols too.

That's an implementation detail users should not care about.

The bigger question is... why don't we replace the login/password combination with just a string of randomly generated characters and call it a day?

Why protect these strings of random characters from users, call them passkeys and advertise them on all street corners?

Feels like a devil's plot to strip us from all the rights to our devices.

public/private keypairs (and therefore passkeys) provide cryptographically secure anti-phishing properties that passwords cannot.

> How are passkeys different from API keys or just random chains of characters?

As far as I understand it, in the same way that a public/private keypair differs from a random chain of characters you are used to shoving into the "Authorization: Bearer XXXXXXX" header.

> How are passkeys different from API keys or just random chains of characters?

Passkeys are encrypyed so they can't be simply copied off your device.

They can most definitely be copied off the device, and the decryption key is in memory.

So how are they better than API keys if I can not even backup them?