FIDO2

FIDO2 replaces shared secrets with asymmetric key pairs generated during registration. The private key never leaves the user's authenticator device, while the public key is stored on the server. During authentication, the server sends a cryptographic challenge that the authenticator signs with the private key, proving possession without ever transmitting the secret itself. This eliminates credential database breaches as a threat vector, since servers store only public keys that are mathematically useless to attackers.

Each FIDO2 credential is cryptographically bound to a specific Relying Party ID (the domain of the service). The browser or platform automatically verifies the origin of the requesting site before allowing the authenticator to sign a challenge. If an attacker creates a lookalike phishing site at model-serving-evil.com, the authenticator will refuse to respond because the origin does not match the registered model-serving.com domain. This provides phishing resistance by design, not by user vigilance.

The Web Authentication API (WebAuthn) is the browser-side component of FIDO2, providing a standard JavaScript interface for web applications to interact with authenticators. Key operations include:

• navigator.credentials.create() for registration
• navigator.credentials.get() for authentication
• Support for attestation (verifying authenticator provenance) and assertion (proving user presence) This API enables seamless integration with model serving dashboards and admin consoles without proprietary plugins.

The Client to Authenticator Protocol (CTAP2) defines how external authenticators communicate with the client platform. It supports multiple transport methods:

• USB (CTAP over HID)
• NFC for tap-and-go mobile authentication
• Bluetooth Low Energy for wireless security keys CTAP2 also enables resident keys (discoverable credentials) stored directly on the authenticator, allowing passwordless login without entering a username first. This is critical for securing administrative access to inference endpoints from any device.

FIDO2 supports flexible authentication postures for model serving infrastructure:

• Passwordless mode: The authenticator alone provides sufficient proof, using built-in user verification like biometrics (fingerprint, face) or PIN. This is the strongest configuration for admin access.
• Second-factor mode: The authenticator is used alongside a traditional password, providing a step-up from legacy MFA while maintaining backward compatibility during migration. Both modes resist credential stuffing, SIM swapping, and man-in-the-middle attacks that compromise time-based one-time passwords (TOTP).

During registration, authenticators can provide an attestation statement—a cryptographic proof of the authenticator's make, model, and security properties. This allows the relying party to enforce policies such as:

• Requiring FIPS 140-2 certified hardware tokens for production model access
• Blocking software-based authenticators for high-risk operations
• Verifying that private keys are generated and stored in a secure element or Trusted Platform Module (TPM) This provides verifiable trust in the authenticator itself, not just the user.

The browser and platform API that enables web applications to create and use strong, attested, scoped public-key credentials for passwordless authentication. It is the client-side component of FIDO2.

• Key Mechanism: navigator.credentials.create() generates a new key pair; navigator.credentials.get() retrieves and uses it.
• Scope: Credentials are bound to a specific Relying Party ID (origin), preventing phishing across domains.
• Attestation: Provides cryptographic proof of the authenticator's provenance and capabilities.

The transport-layer protocol that defines how a client device (browser, OS) communicates with an external roaming authenticator (security key, phone) over USB, NFC, or BLE. It is the external authenticator component of FIDO2.

• CTAP2.1: Introduced enterprise features like credential management and user verification methods.
• Hybrid Transport: Enables cross-platform authentication using a phone as a roaming authenticator via a QR code and BLE handshake.
• Pin Protocol: Establishes an encrypted channel for PIN-protected authenticators to prevent eavesdropping.

A FIDO2 credential stored directly on the authenticator's persistent memory, containing the Relying Party ID and a user handle. This enables a fully passwordless, usernameless first-factor experience.

• Usernameless Flow: The authenticator presents a list of available credentials for the site, eliminating the username input step.
• Storage Limits: Roaming authenticators have a finite number of resident key slots, typically 25-100.
• Enterprise Attestation: Allows organizations to identify specific authenticators and enforce device-bound policies.

The practice of generating and storing the Relying Party's private key within a FIPS 140-2 Level 3 certified HSM rather than on the application server. This protects the credential database from server-side breaches.

• Key Wrapping: The HSM encrypts the private key material, ensuring it never exists in plaintext in application memory.
• Signing Operations: All cryptographic assertions are performed inside the HSM boundary.
• Compliance: Meets stringent regulatory requirements for securing cryptographic material in financial and government model serving environments.

A consumer-friendly synonym for FIDO2 multi-device credentials that are synced across a user's devices via a platform cloud account (e.g., iCloud Keychain, Google Password Manager). They are fundamentally FIDO2 credentials.

• Multi-Device Sync: Eliminates credential loss when a device is replaced, improving user recovery.
• Cross-Device Authentication: Uses a QR code and BLE proximity check to sign into a new device using a phone.
• Phishing Resistance: Retains the origin-bound, public-key cryptography model of FIDO2, making them unphishable.

The process by which an authenticator proves its make, model, and security properties to the Relying Party during registration. The FIDO Metadata Service (MDS) provides a centralized repository of verified authenticator metadata.

• None Attestation: The simplest form, providing no authenticator data, suitable for most use cases.
• Basic Attestation: Uses a batch certificate to identify the authenticator model.
• Privacy CA: Anonymized attestation that proves authenticity without revealing a unique device ID, preventing tracking.