← Back to work WebAuthn · Biometric Security · Enterprise SaaS

WebAuthn Biometric Approval Workflow

Problem

High-stakes document approvals — purchase orders, payments, goods-received notes — were protected by nothing stronger than a password. Anyone holding an approver’s login could approve a six-figure payment; there was no proof that the specific human clicking “Approve” was actually present and consenting to that specific decision.

Architecture

Two distinct moments, two distinct WebAuthn ceremonies:

Enrollment happens once, outside the approval flow entirely. A user registers a device through the authorization server’s own portal; their browser triggers the OS-level biometric prompt (fingerprint, face, Windows Hello), and what comes back isn’t the biometric itself — it’s a public/private key pair scoped to that device. Only the public half is ever stored, and biometric approval can’t be used by anyone who hasn’t enrolled first.

Verification happens per-decision, not per-login. Someone can log into the system with a plain password all day and never see a biometric prompt — each approval workflow (PO, GRN, Payment, etc.) carries its own “requires biometric approval” setting. When an approver acts on a document under one of those workflows, the system triggers a second WebAuthn ceremony bound to that specific document, not the general session. It gets one attempt: a failed biometric scan doesn’t retry, it falls back immediately to a real password challenge against the person’s actual credentials. A successful check produces a short-lived, single-use proof — “this exact person verified for this exact document, moments ago” — that expires within about two minutes.

Key engineering decisions

Result

Live in production with one customer on document-approval workflows (purchase orders, payments, goods-received notes), with a second customer’s rollout in progress. Owned solution design, testing, and the customer-facing demos.