A typical passkey flow is composed of 4 main steps, depicted below:
This flow happens once for registration and for each subsequent authentication or signature request. The main difference is the browser APIs used to trigger the passkey prompt in step (1):
navigator.credentials.create
(as described in this guide). navigator.credentials.create
triggers the creation of a new passkey.navigator.credentials.get
. See this guide for more information. navigator.credentials.get
triggers a signature prompt for an existing passkey.Our SDK has integrated passkey functionality, and we’ve built examples to help you get started.
@turnkey/http
has a helper to trigger passkey registration (getWebAuthnAttestation
). You can see it in action in our with-federated-passkeys
example: direct code link
@turnkey/webauthn-stamper
is a passkey-compatible stamper which integrates seamlessly with TurnkeyClient
:
@turnkey/viem
is a package wrapping all of the above so that you work directly with Viem without worrying about passkeys. See this demo.Regardless of whether you use our helpers and abstractions, take a look at our registration and authentication options guide. This will help you choose the right options for your passkey flow.
If you have questions, feedback, or find yourself in need of an abstraction or integration that doesn’t exist yet, please get in touch with us! You can
We’re here to make this as easy as possible for you and your team!
If you’re wondering how to create independent, non-custodial wallets for your end-users, head to Sub-Organizations. In short: you’ll be able to pass the registered passkeys as part of a “create sub-organization” activity, making your end-users the sole owners of any resource created within the sub-organization (including private keys). Your organization will only have read permissions.
A typical passkey flow is composed of 4 main steps, depicted below:
This flow happens once for registration and for each subsequent authentication or signature request. The main difference is the browser APIs used to trigger the passkey prompt in step (1):
navigator.credentials.create
(as described in this guide). navigator.credentials.create
triggers the creation of a new passkey.navigator.credentials.get
. See this guide for more information. navigator.credentials.get
triggers a signature prompt for an existing passkey.Our SDK has integrated passkey functionality, and we’ve built examples to help you get started.
@turnkey/http
has a helper to trigger passkey registration (getWebAuthnAttestation
). You can see it in action in our with-federated-passkeys
example: direct code link
@turnkey/webauthn-stamper
is a passkey-compatible stamper which integrates seamlessly with TurnkeyClient
:
@turnkey/viem
is a package wrapping all of the above so that you work directly with Viem without worrying about passkeys. See this demo.Regardless of whether you use our helpers and abstractions, take a look at our registration and authentication options guide. This will help you choose the right options for your passkey flow.
If you have questions, feedback, or find yourself in need of an abstraction or integration that doesn’t exist yet, please get in touch with us! You can
We’re here to make this as easy as possible for you and your team!
If you’re wondering how to create independent, non-custodial wallets for your end-users, head to Sub-Organizations. In short: you’ll be able to pass the registered passkeys as part of a “create sub-organization” activity, making your end-users the sole owners of any resource created within the sub-organization (including private keys). Your organization will only have read permissions.