How user registration works with passkeys
User registration is a WebAuthn ceremony, where a User (you) interacts with a Client (your web browser) to create a public key credential (your passkey) on an Authenticator (such as a security key, Google Password Manager, or iCloud Keychain).
This new credential is scoped to a specific Relying Party (a web application), which means that the User can only use the credential on the domain of that web application. The Relying Party also associates the credential with the User's account.
1Create user data
Start by selecting a unique, random user name and display name to create the User's Relying Party account, which you'll associate later with a public key credential.
2Get a challenge and other registration options
The Authenticator needs parameters (registration options) that specify the desired attributes that a new credential must have to satisfy the security requirements of the Relying Party.
The registration options must include a challenge and a unique user ID for the account. The challenge must be randomly generated by the Relying Party in a trusted environment, such as on the server-side, to avoid replay attacks.
Additionally, the registration options must supply User account attributes such as a user name and display name.
For this demo, you will send the User data you selected earlier to the Relying Party Server and get back an object with the required registration options.
3Create the passkey credential
The Relying Party calls the navigator.credentials.create() method from the WebAuthn API in the Client with the registration options as a parameter.
The Client then connects with an available Authenticator and passes down the registration options. The Authenticator can only create a credential if it can meet the criteria defined in the registration options.
Additionally, the User must indicate consent to create a credential and proceed with the registration ceremony. As such, the Authenticator tests for User's presence by showing a UI that prompts the User to provide an authorization gesture, which is a physical interaction with the Authenticator (such as a tap or biometric input).
Follow any on-screen prompts you get to interact with the Authenticator.
4Verify the passkey credential
The Relying Party Client Application needs to send the attestation response to the Relying Party Server, which includes the credential public key, the credential ID, the signed challenge, and additional information, such as attestation regarding the provenance and characteristics of the Authenticator.
The Relying Party Server needs to verify the attestation response by checking its signed challenge to confirm that a legitimate device created the credential.
5Show the passkey credential public key
Once the Relying Party Server verifies the attestation, the server stores in a database record your credential public key, credential ID, and other attestation response data. The server links that data with your user account attributes, such as the user.id and user.name, to effectively create a User's Relying Party account.
The Authenticator is the only element that has access to your credential private key, which you'll need from now on to authenticate with the Relying Party and access your account.
Once you complete this user registration demo with passkeys, you'll see your credential public key in PEM format.