Basically, Webauthn works by having the token sign some data using a per-website private key. The default U2F/FIDO2 model was to use a single secret on the tok

Basically, Webauthn works by having the token sign some data using a per-website private key. The default U2F/FIDO2 model was to use a single secret on the token, and deterministically generate a public-private keypair as required. At registration the token provided some opaque bytes to the website, and the website must supply those bytes back to the token when trying to authenticate. Registration: 1. Token generates random seed 2. Token calculates public/private keypair by combining seed with global secret 3. Token signs registration request using private key 4. Token returns seed, public key, and registration request to server 5. Server stores seed and public key in user's database entry Authentication: 1. User provides username 2. Server looks up user's seed and public key in user database 3. Server provides seed to token 4. Token calculates public/private keypair by combining seed with global secret 5. Token signs authentication request using private key 6. Token returns signed authentication request to server 7. Server validates authentication request against stored public key, and user is now authenticated The biggest benefit of this is that the token is quite trivial to create as there is no need to store a per-website secret on it. One secret can be securely used to authenticate with an infinite number of websites without any security or privacy risks. Passkeys use resident keys. This basically means that the seed is not stored on the server, but on the token. The biggest benefit of this is that you can also get rid of the username in the authentication process. Registration: 1. Token generates public/private keypair 2. Token signs registration request (which includes unique token identifier) using private key 3. Token stores private key, together with website URL 4. Token returns public key, and registration request to server 5. Server stores public key and unique token identifier in user's database entry Authentication: 1. Token looks up public/private keypair using website URL 2. Token signs authentication request 3. Token returns authentication request and unique token identifier to server 4. Server looks up user's entry in user database by unique token identifier 5. Server validates authentication request against stored public key, and user is now authenticated And before you ask: no, I have no idea how this is supposed to work if you have multiple accounts on the same website either.