What is WebAuthn?
WebAuthn is a W3C API for creating and using public-key credentials scoped to a relying party. It can support passwordless sign-in or act as an additional factor. Its verifier binding provides phishing resistance when registration and verification are implemented correctly. Pomerium uses WebAuthn for clientless device identity checks. Pomerium policy, not WebAuthn itself, makes the authorization decision.
Why it matters
WebAuthn replaces reusable shared secrets with public-key credentials that are bound to a relying party. This design can resist phishing and keep the private key in an authenticator.
How it works
- During registration, the relying party sends a challenge and options to the browser, and an authenticator creates a scoped key pair.
- During authentication, the browser gives the authenticator a fresh challenge for the same relying party.
- The authenticator signs the ceremony data, and the relying party verifies the signature, challenge, origin, and relying-party binding.
Example
A user registers Touch ID through a protected route, and Pomerium later requires a fresh WebAuthn check before it allows access from that registered device.
Pomerium boundary
Pomerium Core and Enterprise can use WebAuthn for clientless device identity on protected routes. Enterprise also adds device enrollment approval and management. The route policy uses the resulting device context for its access decision.
Limits and non-claims
- WebAuthn device identity does not provide complete operating-system posture or hardware inventory.
- Deployments need secure enrollment, recovery, replacement, and revocation processes.
- A valid WebAuthn assertion authenticates a credential but does not by itself authorize the requested resource.
Evaluation checklist
- Does the verifier validate challenge, origin, relying-party identifier, signature, and authenticator flags?
- Who controls credential enrollment, recovery, replacement, revocation, and weaker fallback methods?
- Does policy avoid treating one WebAuthn assertion as device posture or resource authorization?
