Learn about the difference between WebAuthn discoverable and non-discoverable credentials
Passkeys are primarily driven by the use of discoverable credentials. Discoverable credentials are a mechanism provided by the WebAuthn specification that allows for seamless authentication without the user having to provide either a username or password. In fact, WebAuthn credentials are determined to be passkeys based on their “discoverability”. In this section we are going to discuss discoverable credentials, and their alternative non-discoverable credentials.
It’s important in our context of passkeys to focus primarily on discoverable credentials; a WebAuthn credential is not considered a passkey unless it’s discoverable.
“Discoverable” refers to the ability for a relying party to attempt to utilize a credential on an authenticator without the user providing a user handle. A discoverable credential is created when the registration create() ceremony is completed. In this flow, a private key that is associated with a user handle is generated on the authenticator.
During authentication, the relying party will send an authentication request that is not specific to any user, or credential. If authentication is successful, meaning a valid credential was found on an authenticator for the specified domain, the client will relay to the relying party the signed challenge, and the user handle associated to the user attempting to authenticate.
Note that there is not a single credential used for every user account - the credential is still origin bound, and relates only to one user handle.
The user handle can be thought of as a unique identifier used to identify an account. Passkey prompts provided by the browser and operating system may display a list of passkeys, should more than one credential exist on an authenticator for a specific domain. It’s important that this user handle resonates with the user, to aid them in selecting a specific passkey should they need to make a choice.
While non-discoverable credentials are not considered passkeys, you should still be aware of them as there are still a number of valid scenarios where your application will need to support the use of them - especially as they are still valid WebAuthn credentials. These are credentials that cannot be generically invoked by a relying party. Instead a user will need to prompt the relying party with a username (user handle) to have the application provide a list of credential IDs to denote which credential(s) can be leveraged for authentication.
Let’s say the user, tacocat, has registered credentials ABC, and DEF. The user will use the client application to provide their username to the relying party. The relying party will then find all of the credentials belonging to tacocat, and include them in the object containing the authentication challenge provided back to the client. If the user is unable to provide a signature from credentials ABC, or DEF, then they will be unable to authenticate.
Supporting non-discoverable credential flows is important for two distinct reasons:
A user may be using a pre-FIDO2 authenticator that does not support discoverable credentials
A user may be using an authenticator that does not have available room for more discoverable credentials
This will be especially important for consumer use cases where you may not have control over the types of authenticators that your user base will attempt to leverage.