Auth

Passkeyd show an implementation using email as a unique string identifier for accounts. You can use just username but then recovery via email not be an option.

Login/Registration

Login and Registration follows a similar flow.

1. The client choses a unique string identifier (username or email) and requests an auth challenge from the server.
2. The server stores a challenge and sends to client
3. The client choses how they want to create a passkey and signs the challenge and send it back. If you have a nearby bluetooth camera device that supports WebAuthN you can get the option to scan a qr code to create the passkey on that device. Authenticating with a portable device is preferable for future flexibility.
4. The server verifies the challenge and the WebAuthN flow is complete and the server can create an authenticated session for the user. Passkeyd chooses to use JWT tokens for sessions.

Multiple Passkeys for one account

Passkeyd supports adding additional passkey credentials to the same account. This flow can be triggered from the account page and follows the same flow as Login/Registration.

Lost/Transfer device flow

Passkeyd has built in examples for both giving the user recovery keys after successful registration and using a recovery email.

WebAuthN Options

This is a non exhaustive list of WebAuthN registration options. The options you choose will depend on your preferences and security requirements.

residentKey

• "discouraged" Won't consume discoverable credential slots on security keys, but also won't generate synced passkeys on Android devices.
• "preferred" Will always generate synced passkeys on Android devices, but will consume discoverable credential slots on security keys.

userVerification

• "discouraged" Won't perform user verification if interacting with an authenticator won't automatically perform it (i.e. security keys won't prompt for PIN, but interacting with Touch ID on a macOS device will always perform user verification.) User verification will usually be false.
• "preferred" Will perform user verification when possible, but will skip any prompts for PIN or local login password when possible. In these instances user verification can sometimes be false.
• "required" Will always provides multi-factor authentication, at the expense of always requiring some users to enter their local login password during auth. User verification should never be false.

authenticatorAttachment

• "cross-platform" Browsers will guide users towards registering a security key, or mobile device via hybrid registration.
• "platform" Browser will guide users to registering the locally integrated hardware authenticator.

Validating FIDO conformance

Passkeyd underlying WebAuthN implementations are Fido conformant but since the solution is using server actions the server endpoints does not match the server structure described here

Before the test suite can validate your solution you need to expose additional endpoints matching the document linked above.

To test that your solution is FIDO conformant the FIDO alliance provides a test suite.

Here is a guide by SimpleWebAuthN on how to run it towards your application.