Dec 01, 2025
Have you heard about passkeys? If not, this blog is for you. Passkeys are a relatively new way to authenticate in mobile and web applications—and you may already use them. For example, when you use Face ID or your fingerprint in your banking app instead of entering a password, you're using a passkey.
Below, I'll explain how they work, the types that exist, why you should start using them, and how to implement them in a project.

How Passkeys Work
When a user logs into an application or website using a passkey, there are four main parts:
-
Authenticator: This can be your phone, computer, or a physical security key. It keeps your private key safe and uses biometrics (such as a fingerprint or face) or a PIN to unlock it; this is where your private key resides.
-
Relying Party: This is the service you're logging into (like Okta, Microsoft, or Google). It stores your public key, not your password.
-
Client: Usually your browser or app. It connects everything and manages the communication.
-
User: That's you, simply clicking "Login" or using your fingerprint.
Your private key never leaves your device. The website only receives a public key, which can verify your credentials but cannot steal them. This is what makes passkeys so secure; they cannot be phished or reused.
Authentication Process (Passkey Sign-in)

-
User login request
The user clicks Login in the client (browser/app). The Relying Party (RP) receives the request.
-
Relying Party sends a challenge.
The Relying Party generates a random WebAuthn challenge and sends the request options to the client.
-
Authenticator proves it’s you.
The client forwards the challenge to the authenticator (phone/laptop/security key).
-
User verifies locally with biometrics or PIN in secure hardware (Secure Enclave / TEE / TPM / hardware key).
-
The authenticator signs the challenge with the private key bound to the Relying Party ID.
-
-
Client returns the signed challenge.
The client sends the assertion (credential ID + authenticator data + signature) back to the Relying Party.
-
Relying Party verifies and finishes sign-in
The Relying Party uses the stored public key to verify the signature and authenticator data.
If valid, authentication succeeds; otherwise, it fails.
Why is this secure?
-
No secrets are shared: the private key never leaves the device.
-
Strong user verification: biometrics/PIN occur locally inside secure hardware.
Main Types of Passkeys
There are two main types of passkeys, depending on where they are stored.
1. Device-Bound Passkeys (Single-Device Passkeys)

These are stored locally on one specific device.
You can only use them on that device — like a YubiKey, a Windows Hello setup, or a mobile passkey tied to your phone.
2. Synced Passkeys (Multi-Device Passkeys)

These are synced across devices through cloud storage like iCloud Keychain, Google Password Manager, or 1Password.
They let you log in on your phone, tablet, or computer using the same credentials — but always safely encrypted.
Types of Device-Bound Passkeys
Device-bound passkeys can use different connection methods:
Mobile Device-Based

-
Bluetooth Passkey – Connects phone and computer using Bluetooth.
-
QR Code Passkey – Utilizes a QR code to securely pair devices.
Physical Security Key

-
USB Passkey – Similar to a YubiKey, connected via USB.
-
NFC Passkey – Uses near-field communication (tap to authenticate).
-
Bluetooth Security Key – Wireless for devices without USB ports.
On-Device Biometric or PIN

-
Mobile Passkey with Face ID or PIN – Unlocks with biometrics on mobile.
-
Computer Passkey with Windows Hello or Touch ID – Integrated authenticator.
Synced Passkeys (Cloud-Based)

Cloud passkeys let you use the same login securely across all your devices.
They use encrypted storage and sync through providers like:
-
iCloud Keychain
-
Google Password Manager
-
1Password, Bitwarden, Keeper, NordPass
Your private keys stay encrypted locally, while only the public information is shared.
How to Test Passkeys
If you want to test passkeys before defining the scope, here are some playground pages where you can test registration, login, and different passkey configurations.
Here’s what the process looks like:
-
Go to webauthn.io
You’ll see two main buttons: Register and Authenticate.
-
Click Register
Choose your preferred authenticator (Windows Hello, Android phone, iPhone, or security key).
-
Approve the request
Depending on your setup, you might use a fingerprint, Face ID, or scan a QR code to connect your phone.
-
Confirm pairing
The browser handles the secure exchange using the FIDO2 protocol — everything is encrypted automatically.
-
Login
After registration, click Authenticate. Your browser will prompt you to use the same passkey, and you’ll log in instantly.
Notice that Passkeys are agnostic to the system, which means that it doesn’t matter if you’re on Windows, Android, Linux, or macOS.
The protocol (WebAuthn) handles encryption, decryption, and verification behind the scenes.
Cloud-based Passkey registration Example

Physical Security Key authentication

Testing in a playground gives you a starting point for defining your needs before implementing passkeys in your project.
How to Implement Passkeys
As you can see, there are different types of passkeys, but they all work the same way behind the scenes. However, implementation requires defining the scope based on platform type, application type, and business needs.
At Oshyn, we help our clients develop the best solution, from User Experience design to choosing the right Relying Party, adapting existing authentication systems, and handling critical changes such as:
-
Redesigning the flow
-
Defining the best approach for users based on business needs
-
Ensuring security
The following are examples of implementations that Oshyn performed:
-
Retirement system with Okta as a Relying Party, using Okta's authentication services. In this case, we implemented the following:
-
Adapted Okta's standard flow for our business needs, such as adding a custom registration flow within the Okta login flow for the passkey.
-
Passkey registration using business data such as SSN, DOB, and account number.
-
Synced Passkeys for desktop—iCloud Keychain for macOS and Windows Hello for Windows users
-
Device-Bound Passkeys for users of the native mobile application on Android and iOS
-
Deleting passkeys when users block their accounts
-
Managing passkeys from the security center
-
Support for multiple passkeys. i.e., one for mobile devices and one for desktop devices.
-
-
Mobile application for iOS and Android
-
Creation of a bridge to communicate between the native mobile application and the mobile device, using Device-Bound passkey, accepting only iCloud Keychain for iOS or Google Password Manager for Android.
-
As you can see in the example, despite passkeys seeming simple to implement, they must be adapted in practice. Another example of this customization is a mobile banking system that accepts only one passkey—no username is needed, only biometric authentication, with one passkey per user. To add an extra security layer, only Device-Bound passkeys are accepted, so the passkey is stored on that unique device.
Wrapping Up
Passwords have always been the weakest part of authentication; for this reason, passkeys are one of the best alternatives to replace or complement them (as a second factor of authentication).
Passkeys are not only more secure but also simpler, improving the user experience.
How Oshyn Can Help
Implementing passkeys is more than just integrating an API; it requires strategic adaptation to your existing ecosystem. At Oshyn, we guide you through the entire process: Redesigning the flow to ensure a seamless UX, selecting the optimal Relying Party (like Okta or a custom solution), adapting your registration and account management systems, and ensuring support for multiple passkey types (Synced vs. Device-Bound) based on your specific business and security needs. We turn the technical requirements of the WebAuthn standard into a secure, practical, and highly customized solution for your users. Contact us to get started.
Related Insights
-
CASE STUDY
A New Mobile App Connects the Entire Customer Experience
-
BLOG
Fernando Torres
Stop Guessing, Start Testing
Why Enterprises Need to Introduce Front-End Testing to Improve the User Experience
-
BLOG
Wladimir Moyano
Automate Windows Security Updates for AWS EC2 Instances with AWS Systems Manager
-
BLOG
Oshyn
Is Test Automation Right for Your Project?