FIDO2 (WebAuthn / CTAP)

FIDO2 (FIDO — Fast IDentity Online) is an open authentication standard developed by the FIDO Alliance and W3C that enables passwordless authentication through public key cryptography. It is defined by two specifications that operate at different points in the same flow: WebAuthn, the browser API through which a relying party asks for a credential, and CTAP (Client to Authenticator Protocol), the protocol through which the client platform talks to the authenticator that holds it. Together they produce a credential that is scoped to one origin and cannot be phished, replayed against another site, or extracted as a reusable secret.

WebAuthn and CTAP

WebAuthn is the W3C standard that relying parties actually program against. It defines the JavaScript registration and authentication ceremonies, carries the relying party's requirements — user verification, resident credentials, acceptable authenticators — into the platform's credential prompt, and returns a signed assertion bound to the requesting origin. It is supported by every major browser, which is why FIDO2 is a deployment decision rather than a platform bet.

CTAP covers the link the browser cannot see into. CTAP2 lets external authenticators — USB, NFC, and Bluetooth Low Energy security keys — register credentials and produce assertions on behalf of a client platform, while CTAP1 preserves interoperability with the legacy FIDO U2F keys already in circulation. A relying party is largely unaware which CTAP version was involved, but the distinction determines what an existing fleet of security keys can be used for.

Authenticator Types

Platform authenticators are built into the device — Windows Hello, Touch ID, Face ID, Android biometrics — and keep private keys in the device's secure element, a TPM or a Secure Enclave. Because the user authenticates with the gesture that already unlocks the device, these authenticators are what make passwordless sign-in feel like less work than a password, and they are the foundation of FIDO2 Passkeys.

Roaming authenticators are external hardware security keys such as YubiKey, Titan, or Feitian devices. They move between machines and platforms, commonly carry attestation that lets a relying party verify what kind of device produced a credential, and serve either as the primary credential in high-assurance environments or as the backup authenticator that makes a device-bound passkey strategy survivable.

WebAuthn Level 3

Level 2 is the deployed baseline; Level 3 has been proposed for advancement to W3C Recommendation, and it standardizes several things relying parties had been solving individually. Four additions change how a deployment is built:

  • getClientCapabilities() asks the client platform what it actually supports — conditional mediation, a user-verifying platform authenticator, the signal methods, related-origin handling — before the relying party commits to a flow. It replaces the feature detection and user-agent guessing that made staged rollouts brittle.
  • Signal methods (signalAllAcceptedCredentials(), signalUnknownCredential(), signalCurrentUserDetails()) let a relying party tell a credential manager which credentials it still accepts and how the account is now named. This is the missing half of credential lifecycle management: without it, a passkey deleted server-side is still offered to the user indefinitely, and the resulting failed sign-in attempts look like a broken deployment rather than a stale entry.
  • Related-origin requests allow one credential to be used across a defined set of associated origins, which matters to any organization operating country or brand domains over a single account namespace and otherwise forced to enrol a separate credential per domain.
  • JSON serialization helpers (parseCreationOptionsFromJSON(), parseRequestOptionsFromJSON()) remove the manual base64url conversion that has been a reliable source of integration defects, and the PRF and largeBlob extensions carry forward credential-derived key material and small amounts of authenticator-side storage.

Relationship to Other Technologies

  • FIDO2 Passkeys: The user-facing form of a FIDO2 credential, either synced across devices by a credential manager or bound to a single authenticator
  • FIDO U2F: Legacy second-factor standard, still usable through CTAP1
  • UAF (Universal Authentication Framework): Earlier FIDO specification for first-factor biometric authentication
  • W3C Digital Credentials API: Shares WebAuthn's navigator.credentials entry point and its browser-mediated consent model, but requests an attribute presentation from an identity wallet instead of authenticating a returning user — the two are complementary rather than alternatives
  • Credential Exchange Format and Protocol (CXF / CXP): FIDO Alliance specifications for moving credentials between credential managers rather than between a client and a relying party, so they sit beside WebAuthn and CTAP rather than inside either; the Passkeys article covers what portability changes for a deployment

Key Advantages of FIDO2

  • Strong authentication: Origin-scoped cryptographic credentials resistant to phishing, credential reuse, and theft of a server-side secret
  • Passwordless experience: Removes passwords entirely, or removes their value as a phishing target where they remain as a secondary factor
  • Attestation support: Authenticators can prove what they are, which is how assurance requirements are enforced rather than assumed
  • Interoperability: Open standards implemented by every major browser and platform, with certification behind the authenticators
  • Privacy protection: Per-relying-party credentials cannot be correlated across sites
  • Scalability: Supports consumer and enterprise deployments at different assurance levels with the same primitives

Key Challenges of FIDO2

  • Coordinated adoption: Requires relying parties, browsers, and authenticator vendors to move together, so the constraint is usually the least capable participant
  • User education: Choosing between platform authenticators, security keys, and passkey types is a decision users cannot make unguided
  • Legacy integration: Retrofitting FIDO2 into existing identity infrastructure and applications that assume a password can be substantial work
  • Account recovery: Recovery is the weakest authenticator on the account, and a phishing-resistant credential recovered by a knowledge-based question is only as strong as the question — which makes recovery an identity proofing decision rather than an authentication one
  • Cross-platform flows: Using one ecosystem's device to sign in on another has improved but remains the roughest part of the experience; moving a credential between providers is a different problem, addressed by CXF and CXP
  • Enterprise management: Provisioning, monitoring, and revoking credentials at scale still depends on the credential manager, since the signal methods inform it rather than control it
  • Attestation is a point-in-time statement: Attestation and the AAGUID describe the authenticator that created a credential; once credentials can be exported between credential managers, they no longer describe where it is held today
  • Regulatory compliance: Biometric and attestation data handling has to satisfy privacy regulation such as the GDPR