- automated processes
- implementing for instance single sign-on
The server needs the public key to verify the signature. The public key can be:
- added by the administrator of the server in a public key store (generally known as the authorized keys)
- asked during a registration process where the client creates a keypair for the application and sends the public key back.
- Client: I want to sign in.
- Server: Send data and asks the client to sign it
- Client: Create a signature with the private key and send it back
If the verification succeeds, the client is logged in.
The private keys are the identity key.
It then need to be stored and handled carefully, and no copies of the private key should be distributed. The private keys used for user authentication are called identity keys.
For instance, if a server considers the key trustworthy, the server marks the key as authorized in its authorized_keys file.
Such keys are called authorized keys.
SSH - Authorized Keys
SSH stores the Authorized public Keys in the authorized_keys file.
- Client: I want to create a new account.
- Server: Send me a public key.
- Client: Create a new keypair and send the public key
- Server: Registration complete
The creation of the keypair is generally done via a physical security key.
Note that WebAuthn is part of the FIDO2 framework, a set of technologies that enable passwordless authentication between servers, browsers, and authenticators.