How Passkeys Work: WebAuthn, Phishing, and the Reality of Portability

A passkey is a FIDO credential, functioning as a unique public/private key pair generated by an authenticator (such as a smartphone, laptop, or hardware security key) specifically for a single relying party (a website or application). Unlike traditional authentication methods, this design ensures that the private key never leaves the authenticator in a usable form. By keeping the private key on the device, the system removes the possibility of the secret being intercepted, exfiltrated, or inadvertently exposed by the user.

The core mechanism that defines a passkey is its status as a discoverable credential. In the FIDO/W3C specifications, this means the authenticator can locate the correct credential internally without requiring the site to first provide a username. This capability enables passwordless flows where the user selects an account directly from the authenticator's UI, rather than manually entering identifiers that could be subject to shoulder-surfing or typos.

The technical implementation relies on the WebAuthn "ceremony," which enforces strict cryptographic binding between the credential and the site's origin:

• Registration: The server sends a challenge to the client. The browser identifies the origin (e.g., https://example.com) and passes it to the authenticator, which generates a key pair and signs the challenge, binding the public key to that specific origin.
• Authentication: During sign-in, the browser automatically injects the current origin into the clientDataJSON. The authenticator signs the challenge and the origin. Because the browser—not the site—supplies the origin, the authenticator signature acts as a cryptographic proof that the user is interacting with the legitimate domain.

If an attacker directs a user to a look-alike domain, the browser will report the malicious origin in the clientDataJSON. The authenticator will sign that incorrect origin, and the legitimate server will subsequently reject the signature, as it will not match the expected origin associated with the stored public key.

While synced passkeys stored in cloud vaults (like iCloud Keychain or Google Password Manager) allow for portability via encrypted transfer, device-bound passkeys—typically residing in hardware security keys—are engineered to never export the private key. This trade-off ensures maximum security for high-assurance environments at the cost of requiring secondary keys for redundancy.

The W3C Web Authentication (WebAuthn) specification defines a ceremony—a sequence of browser-mediated cryptographic operations—to facilitate secure registration and authentication. Unlike traditional password-based workflows, the WebAuthn ceremony ensures that the server never receives a shared secret or a password hash, effectively nullifying risks associated with database exfiltration.

The ceremony involves two primary phases:

• Registration: The server issues a cryptographically secure random challenge. The client-side application invokes navigator.credentials.create(), passing the challenge and RP (Relying Party) metadata. If the residentKey attribute is set to "required," the authenticator generates a discoverable credential—a public/private key pair unique to that origin—and returns the public key and credential ID for server-side storage.
• Sign-in: The server sends a fresh, single-use challenge. The application calls navigator.credentials.get(). Upon user interaction (e.g., biometrics or PIN), the authenticator signs the challenge combined with the clientDataJSON object. The server verifies this signature against the stored public key to authenticate the user.

A critical component of this ceremony is origin binding. During authentication, the browser—not the page JavaScript—populates the origin field within the clientDataJSON. Before the authenticator signs the data, it verifies that the origin matches the RP ID. Because the origin is browser-enforced and immutable by site-level scripts, look-alike or phishing domains will either lack a matching registered credential or produce a signature bound to the malicious origin, which the legitimate server will subsequently reject.

Engineers must ensure that the server-side verification logic strictly validates the following:

• Type matching: Ensure the clientData.type is strictly webauthn.get.
• Challenge freshness: Confirm the signed challenge matches the current session's unique, one-time challenge.
• Origin enforcement: Verify that the clientData.origin is an exact match for the expected application domain.
• Cryptographic integrity: Verify the signature over the concatenation of authenticatorData and the SHA-256 hash of clientDataJSON.

By delegating origin verification to the browser and keeping the private key within the hardware-backed authenticator, WebAuthn provides a robust defense against credential interception, provided that developers do not permit bypasses via legacy authentication fallback methods.

During a WebAuthn sign‑in ceremony the browser builds a clientDataJSON object that contains three fields: type, the server‑generated challenge, and origin. The origin is taken directly from the URL of the page that invoked navigator.credentials.get(). This value is not supplied by JavaScript; the browser extracts it from the address bar and verifies it against the relying‑party identifier (rpId) before any cryptographic operation occurs. The resulting JSON is hashed (SHA‑256) and concatenated with the authenticator data; the private key then signs this combined blob.

Because the signature is mathematically bound to the exact origin string, a credential created for https://accounts.google.com cannot produce a valid signature for any other domain, even one that looks similar. When a user is lured to a phishing site such as https://accounts.g00gle-login.com, the browser will either:

• Find no stored passkey for that origin, causing the authenticator to abort, or
• Generate a signature whose origin field is https://accounts.g00gle-login.com. The legitimate server, which expects https://accounts.google.com, will reject the authentication because the origin check fails.

Server‑side verification therefore follows a strict sequence:

// Simplified verification sketch
if (clientData.type !== "webauthn.get") reject;
if (clientData.challenge !== session.challenge) reject;
if (clientData.origin !== "https://example.com") reject;
verifySignature(storedPublicKey,
                signature,
                authenticatorData + SHA256(clientDataJSON));

Only when all three conditions hold does the server accept the login. Because JavaScript cannot alter the origin field, an attacker cannot forge a valid signature for a look‑alike domain, eliminating the classic “enter your password on a fake site” vector.

Practical implications for engineers:

• Never rely on client‑side origin checks; enforce the exact match on the server.
• Configure the rpId to the eTLD+1 (e.g., example.com) to cover subdomains while still protecting against deceptive siblings.
• Ensure that any fallback authentication (password, OTP) is disabled or tightly monitored, because the phishing resistance only applies to the passkey path.

The distinction between synced and device-bound passkeys hinges on the movement of private key material. At the core of the WebAuthn standard, a passkey is a public/private key pair generated by an authenticator. The server stores only the public key, ensuring that even in the event of a database compromise, an attacker gains no secrets capable of authenticating a session.

When implementing these credentials, enterprise architects must weigh the following architectural differences:

• Synced Passkeys: These utilize providers like iCloud Keychain, Google Password Manager, or Bitwarden. The private key material is encrypted and synchronized across the user's devices. While this significantly improves usability and reduces the risk of permanent account lockout, it shifts the security boundary from the local device to the provider’s end-to-end encrypted vault. This approach introduces a dependency on the provider’s ecosystem and account recovery processes.
• Device-Bound Keys: Authenticators such as YubiKeys are designed to prevent the export of private keys entirely. The private key never leaves the hardware secure element. This model offers the highest level of physical assurance, as the key material cannot be duplicated or intercepted by software-based exfiltration. However, it requires a robust manual management policy—typically mandating the registration of multiple physical keys per user to mitigate the risk of loss.

From a technical standpoint, relying parties can identify the class of authenticator through the AAGUID (Authenticator Attestation Global Unique Identifier) returned during the WebAuthn ceremony. While most implementations currently treat all passkeys identically, enterprise environments may choose to enforce hardware-backed attestation for high-security internal resources while permitting synced credentials for general-purpose applications.

Ultimately, synced passkeys prioritize availability and the reduction of friction, whereas device-bound hardware keys prioritize the physical immutability of the credential. For enterprise resilience, the recommended practice for device-bound implementations is the registration of multiple distinct hardware keys per user to prevent the O(m*n) complexity bottleneck and account lockout scenarios associated with single-token failure.

The transition to passkeys introduces a fundamental shift in identity management that necessitates careful architectural planning. At the core of the friction experienced by users and developers is the O(m*n) registration problem: with m services and n devices, a user must independently register each device with each service to maintain access. Unlike traditional passwords, which are portable, device-bound passkeys remain anchored to the authenticator’s secure element, rendering them non-transferable by design.

To mitigate these challenges while maintaining robust security postures, developers should implement the following strategies:

• Maintain Secure Fallbacks: Until the FIDO Credential Exchange Protocol (CXP) reaches maturity and universal implementation, ensure accounts remain accessible via secondary factors. Relying solely on a single synced passkey provider risks total account lockout if that provider or the associated cloud account becomes inaccessible.
• Acknowledge Hardware Constraints: Recognize that hardware-bound authenticators, such as FIPS-validated security keys, are physically incapable of exporting private keys. For high-assurance environments, the only viable strategy is the manual enrollment of multiple physical keys per account, effectively doubling the management overhead for the user.
• Strategic Use of Attestation: Use the Authenticator Attestation GUID (AAGUID) to distinguish between synced passkeys and device-bound hardware authenticators. This allows developers to enforce higher security requirements—such as requiring hardware-backed keys for sensitive administrative actions—while offering more convenient, synced options for standard user interactions.

The current state of FIDO's Credential Exchange Format (CXF) provides a standardized file structure for data migration, but the protocol for secure cross-manager handovers remains a working draft. Consequently, enterprise architects should avoid designing systems that assume universal, immediate, or seamless portability of credentials between disparate password managers or platform authenticators. Until these standards reach widespread maturity, the hybrid approach of coupling passkeys with a legacy fallback remains the most resilient pattern for preventing accidental user lockouts during the ecosystem's transitional period.