FIDO2 Authentication

FIDO2 eliminates shared secrets by generating a unique public/private key pair for each relying party. The private key never leaves the user's authenticator, making remote credential theft impossible. Unlike passwords or one-time codes, the authentication response is scoped to the specific origin (domain) , so a fake website cannot replay credentials captured from a legitimate site. This binding of credentials to origin is the core mechanism that defeats man-in-the-middle attacks.

The W3C Web Authentication (WebAuthn) specification provides a standard browser JavaScript API for creating and using public key credentials. Developers call navigator.credentials.create() for registration and navigator.credentials.get() for authentication. The API abstracts away the underlying authenticator hardware, supporting:

• Platform authenticators: Built-in biometrics like Touch ID, Face ID, or Windows Hello
• Cross-platform authenticators: External USB, NFC, or BLE security keys
• Attestation: Cryptographic proof of the authenticator's make and model

The Client to Authenticator Protocol (CTAP) defines how a browser or OS communicates with an external authenticator over USB, NFC, or Bluetooth Low Energy. CTAP2, the current version, enables:

• User verification: Requiring a PIN, biometric, or button press before signing
• Resident keys (discoverable credentials): Storing the credential and associated user handle directly on the security key, enabling usernameless login flows
• HMAC-Secret extension: Deriving symmetric keys for encrypting user data at rest

FIDO2 condenses multiple authentication factors into a single user action. A security key or biometric sensor simultaneously satisfies:

• Possession: The user holds the physical authenticator
• Inherence: A fingerprint or face scan unlocks the key's signing capability
• Knowledge (optional): A local PIN can be required to activate the authenticator This unified approach achieves high assurance without degrading user experience, reducing friction compared to SMS codes or authenticator apps.

FIDO2 credentials are scoped per relying party, meaning a unique key pair is generated for each service. No shared identifier links a user's accounts across different websites. The protocol explicitly prevents tracking:

• Authenticators do not expose a global hardware serial number during normal operation
• Attestation can be performed in none or self modes to avoid uniquely identifying the device
• The browser mediates all requests, requiring explicit user consent before releasing credentials

For managed environments, FIDO2 supports enterprise attestation to verify that only approved authenticator models are used. IT administrators can enforce policies via WebAuthn's authenticatorSelection options:

• Require resident key storage for passwordless workflows
• Mandate user verification for high-value transactions
• Restrict allowed attestation conveyance preferences These controls integrate with MDM and endpoint security platforms to enforce corporate authentication standards.

FIDO2 replaces shared secrets with asymmetric cryptography. Each registration generates a unique elliptic curve key pair (commonly ES256 on P-256) scoped to the specific relying party origin. The private key never leaves the authenticator's secure element; only the public key is transmitted to the server.

• Origin binding: Keys are scoped to rpId, preventing phishing across domains
• Challenge-response: Fresh cryptographic nonces prevent replay attacks
• Attestation: Authenticators provide a signed certificate proving their make and model during registration

Software-based FIDO2 authenticators built directly into operating systems and devices. Examples include Apple's Touch ID/Face ID with iCloud Keychain, Windows Hello with TPM 2.0, and Android's biometric stack with Google Password Manager. These leverage existing device biometrics and secure enclaves.

• TPM-backed: Windows Hello binds keys to the Trusted Platform Module
• Multi-device sync: Apple and Google synchronize passkeys across the user's device ecosystem via end-to-end encrypted cloud accounts
• User verification performed locally via fingerprint, face, or device PIN