Skip to main content
A passkey is a public-key credential created and used through WebAuthn, the browser standard behind passwordless sign-in. The user approves an action with the gesture their device already asks for — Face ID, Touch ID, Windows Hello, a fingerprint sensor, or a password manager prompt — and the credential produces a signature. Rhinestone uses passkeys as the signer for embedded wallet smart accounts. The account holds the assets; the passkey authorizes what the account does.

​
What replaces the password

A password is a shared secret: the user knows it and the server stores something derived from it, so a server breach or a convincing imitation of your site can hand that secret to someone else. A passkey is a key pair instead. The authenticator keeps the private key and gives out only the public half, so there is no shared secret to leak. Proving identity means signing a fresh challenge rather than replaying a stored value, and a captured signature authorizes nothing else. For an onchain account the same property does the work of a seed phrase, without the user ever having to hold one.

​
How a passkey signs

  1. Registration. The user’s authenticator generates a key pair. The private key stays with the authenticator; your application registers the public key.
  2. Authorization. Rhinestone prepares the action and issues the data to sign. The authenticator asks the user to confirm with a biometric or device gesture, then signs.
  3. Verification. The account’s validator checks the signature against the registered public key before executing.
The private key is never transmitted. Rhinestone receives the public key and signed WebAuthn responses, not key material. The user gesture is a local check that unlocks the key, not a secret sent anywhere. A fingerprint or face scan never leaves the device, and the authenticator will not sign without it.

​
Passkeys are bound to a domain

A passkey belongs to the hostname namespace it was created on, and the browser supplies that origin itself rather than taking the page’s word for it. A site cannot ask for another site’s credential, which is what makes passkeys phishing-resistant: a convincing copy of your application on a different domain has nothing to request. It also means the domain determines which account the user reaches. Choose the namespace before onboarding users — see Passkeys and domains.

​
Where the passkey lives

This depends on the user’s authenticator and platform, and your application does not choose it:
  • A device-bound passkey stays on the authenticator that created it, often backed by secure hardware.
  • A synced passkey replicates through the user’s platform or password manager, so it survives a lost device and works across the user’s other devices.
Do not assume every user has one or the other. Plan a recovery path rather than relying on sync.

​
What a passkey does and does not decide

A passkey removes the seed phrase and keeps the user’s signing key out of a provider’s hands. It does not by itself describe the full control path of an account. Assess the signing path, the service’s role in preparing and submitting transactions, and the authority held by recovery guardians together. Self-custody covers what the user controls, and Security and self-custody covers the operational detail.

​
Next steps

  • Smart accounts: how the account separates assets from the credentials that control them.
  • Session keys: authorize repeated actions without a passkey prompt each time.
  • Sign up and sign in: the passkey flow in your application.