Skip to main content
Version: v2

Universal Passkeys

A Universal Passkey is a public and private key pair. The private key is generated and stored and never leaves the user’s device. The public key, on the other hand, is sent to the Beyond Identity cloud.

All keys get linked to the user and their devices cryptographically. The keys are compatible with any OS device and can be managed using our APIs.

Example banner

We take care of all the cryptographic key usage under the hood.

  1. Your app asks us to authenticate the user using standard authentication protocols.

  2. We generate a unique challenge and ask the device to locate a passkey, request the user to unlock it, and sign the unique challenge with it.

  3. We verify the signature and if a match is found we tell your system which user was authenticated using the same authentication protocol that initiated the flow.

Benefits of Universal Passkeys

  • Improved user experience. With Universal Passkeys, you can enable seamless passkey enrollment for your users no matter what device platform or browser they are using. Passkey enrollment happens automatically, inline with the first signin. Once enrolled, users can sign in by selecting their passkey (a click or touch) and presenting a biometric rather than entering a password or using a phone app.

  • Enhanced security. Passwords are a major vulnerability as users reuse passwords and are able to share them with others. Passwords are the biggest attack vector and are responsible for a significant percentage of breaches. They also lead to attacks such as credentials stuffing, corporate account takeover, and brute force attacks.

  • Reduced total cost of ownership. Managing passwords is expensive between implementing password complexity policies, managing password expiration and password reset processes, hashing and storing passwords, and monitoring breached password detection.

How passkeys are created

Passkeys are created through binding jobs where a binding link gets generated to bind a passkey to a specific device or browser. This passkey gets stored in the user's device's hardware root of trust (i.e., secure enclave).

MethodWhen to use
RETURNYou want to generate a passkey link and deliver it to your users however you wish (in-line, SMS, email, etc.). This is the suggested method to create a passkey without a user leaving your application. It's also the fastest way to get a binding link.
EMAILYou want to send your users an email with a link to create their passkey. Clicking or tapping the link redirects your user to the Beyond Identity Cloud. The Beyond Identity Cloud then looks up the Authenticator Config associated with that passkey creation link. Finally, it redirects your user to your application using the Authenticator Config's Invoke URL specified.

The Invocation Type has no effect on the passkey creation/binding flow.

The high-level flow for binding a passkey is:

  1. A passkey creation link is created using the Beyond Identity APIs.

  2. The passkey creation link is delivered to the Beyond Identity SDK that is running on your user's device. Beyond Identity uses the delivery method configured to deliver a passkey creation link using the Beyond Identity API.

  3. The passkey creation link is passked to the Beyond Identity SDK bindPasskey() function. A private key gets generated, stored in the device's hardware trust module, and the public key gets stored in the Beyond Identity Cloud.

See Bind a passkey to an identity to learn how.

How authenticate works with passkeys

Beyond Identity uses the industry standard protocol OIDC to verify the identities of your end users. At a high level, your application delegates authentication to Beyond Identity using OIDC. Then, we ask the end user to prove they possess a device with a valid passkey and can unlock that device and passkey.

Modern devices ship with authentication primitives used to unlock the device and any keys stored on the devices. If users can unlock the device, they can prove it trusts them. And thus, they can use the digital key to sign a unique challenge that identifies them to Beyond Identity and your app.

During authentication, Beyond Identity issues a challenge signed by the private keys in the device's hardware, evaluates user and device security risk in real-time, and makes a risk-based access decision based on your security requirements.

How passkeys are stored

Passkeys are stored in Trusted Execution Environments (TEE) wherever they're available.

Examples of Trusted Execution Environments supported by Beyond Identity are:

  • In Apple Devices, keys are stored in Apple T2 chips.

  • In Windows and Linux workstations, keys are stored on Trusted Platform Modules (TPM).

  • In ChromeOS, keys are stored in encrypted envelopes protected by keys on the Titan chip.

  • In AWS, keys can be stored in the Nitro enclaves on instances that support it. They are not persisted.

If no TEE is available, our SDKs automatically fall back to OS-specific security APIs for safe storage on the hard disk. These are typically protected by a master key the OS generates with a knowledge factor as a salt.