AmbiSecure FIDO Validation Server
A FIDO-based passwordless authentication platform designed for enterprises. Strong security, a seamless user experience, and fully controlled, transparent billing — companies integrate it into their websites or applications via a simple JavaScript API and REST endpoints.
Because writing your own attestation verifier is not the project you signed up for.
Server manages user keys
The server manages the user’s key and verifies the signed transactions. The server does not hold on to the client’s private key — it stays on the authenticator.
Per-website key uniqueness
Cryptographic keys are unique at every website. Origin-bound by the FIDO protocol itself, so phishing pages cannot use credentials from a different origin.
Multiple authentication methods
Fingerprint, face recognition, hardware security keys, and biometric authentication via built-in device tools — all flow through the same server-side API.
Simple JavaScript API
Drop-in JavaScript that supports the leading browsers and platforms. The integration cost is hours, not weeks.
REST endpoints
Server-side REST endpoints (e.g. /auth/login/start) for the registration and authentication flows. Language-agnostic.
Transparent billing
Per-active-credential pricing, visible monthly. No surprise overages, no minimum-seat commitments hidden in the contract.
How a webapp calls the validation server.
Two API calls per registration. Two per authentication. The credential never leaves the authenticator.
API key
Issued to your tenant. Scopes the API calls.
Begin
Webapp calls the server to start a registration or authentication.
Browser
JS API talks to the WebAuthn / CTAP2 authenticator.
Verify
Server verifies the signed assertion against your tenant policy.
Done
User is logged in. No password. No phishable seed.
What the validation server actually does.
| Standards | FIDO2 / WebAuthn (W3C); CTAP2.1; FIDO U2F (legacy fall-through) |
|---|---|
| Authentication factors | Hardware security keys, on-device biometrics, platform authenticators |
| Attestation | Verifies signed attestation against the configured trust anchors |
| MDS support | Lookup and policy enforcement against the FIDO Metadata Service |
| Per-tenant policy | Allowed authenticator AAGUIDs, required UV, required attestation conveyance |
| Deployment | Cloud-hosted SaaS by default; on-premises and hybrid options on request |
| Integration surface | Drop-in JavaScript API plus tenant-scoped REST endpoints |
| Billing | Per-active-credential, transparent monthly invoicing |
One platform, isolated tenants, per-tenant policy.
The server is multi-tenant by design. Each relying party gets its own tenant boundary with its own AAGUID allow-list, attestation conveyance policy, user verification posture, and credential store. Tenants do not see each other's data.
Tenant isolation
Every credential, every challenge, every audit record is scoped to a single tenant identifier. Cross-tenant queries are refused at the persistence layer, not just the API layer.
API key per environment
Separate API keys per environment (dev / staging / production). Keys are hashed at rest; the cleartext value is shown once at issuance. Rotation is operator-driven, not on-call work.
Per-tenant policy
Allowed authenticator AAGUIDs, required UV, required attestation conveyance, residency requirements for resident credentials, user-handle namespace — all configured per tenant.
Usage + billing
Active-credential counts, registration volume, and authentication volume are tracked per tenant. The billing line is whatever the operator wants to expose; the metering is honest.
Attestation verification
Packed, FIDO-U2F, TPM, Android-Key, Android-SafetyNet, Apple Anonymous, and None formats are verified inside the server. AAGUID lookups go through a refreshed FIDO Metadata Service mirror.
Origin + RP-ID binding
Every registration locks the credential to a tenant-declared RP-ID and origin set. Mis-matched origins are rejected before any signature is examined, eliminating the phishing-replay surface.
Two ceremonies, four endpoints.
The server’s public surface is small on purpose. Two REST calls per ceremony, scoped by an API key plus a tenant identifier. The browser-side WebAuthn API does the rest.
| POST /register/begin | Returns a PublicKeyCredentialCreationOptions challenge for the user. Tenant policy populates authenticatorSelection, attestation, and excludeCredentials. |
|---|---|
| POST /register/finish | Verifies the authenticator’s signed attestation, applies the tenant’s AAGUID policy, persists the credential. Returns the credential record on success. |
| POST /login/begin | Returns a PublicKeyCredentialRequestOptions challenge. Supports both username-first and discoverable-credential (passkey) flows. |
| POST /login/finish | Verifies the assertion against the stored public key, increments the signature counter, applies tenant freshness policy, emits a tenant-scoped session token. |
| GET /credentials/:userId | Tenant-scoped credential enumeration for account-management surfaces. Includes AAGUID, transports, sign-count, and last-used timestamp. |
| DELETE /credentials/:credentialId | Tenant-scoped credential revocation. Idempotent. |
| Admin / tenant /usage | Internal admin endpoints (separately scoped) for tenant CRUD, key rotation, and usage metering. |
Three deployment shapes, one server image.
Hosted SaaS
AmbiSecure runs the server. Operators receive an admin console, API keys, and a sandbox tenant within a business day. Right for greenfield deployments and proofs of concept.
Operator-hosted
Same container image, deployed into the operator’s cloud account (AWS / Azure / GCP) or on-premises. Right for residency requirements and operators with existing identity-stack ownership.
Hybrid
Verification + tenant data in the operator’s account; usage metering and MDS mirror centrally hosted. Right for operators who want the data plane and don’t want to run the MDS pipeline.
Where the Validation Server sits in the FIDO trust chain.
A FIDO deployment has three actors — authenticator, relying party, validation server. The server is the load-bearing piece in the middle: it owns policy, verifies attestation, and produces the cryptographic decision the relying party trusts.
Authenticator
OnePass Card, FIDO2 Nano SIM, USB key, or platform authenticator. Holds the private key.
Browser / OS
WebAuthn client talks to the authenticator over CTAP2.1. Origin-bound by construction.
Validation Server
Verifies attestation, applies tenant policy, persists credentials. The cryptographic decision lives here.
Relying party
The application doing the sign-in. Trusts the server's decision; never touches a key.
The cryptographic chain that backs every credential.
Every registration produces an attestation statement. The Validation Server walks this chain on every accepted credential.
Authenticator key
Per-credential keypair generated inside the secure boundary.
Attestation key
Per-batch authenticator-issuer key. Signs the registration attestation.
Attestation CA
The vendor / programme CA that signed the attestation key.
MDS BLOB
FIDO Metadata Service entry binding AAGUID to certification, transports, advisories.
Tenant policy
Allow-listed AAGUIDs + UV / attestation conveyance requirements. The policy gate.
From contract to first credential, four steps.
Onboarding is operator-driven, not self-serve. The validation server is a managed engagement; this is the canonical sequence.
1. Scoping conversation
Tenant scope (one relying party? a portfolio?), target authenticators (OnePass Card, embedded secure-element, third-party security keys), deployment shape (hosted / operator-hosted / hybrid), residency requirements, expected credential volume.
2. Tenant provisioning
Tenant identifier issued. API keys for dev / staging / production. Initial AAGUID allow-list + UV / attestation conveyance policy configured. RP-ID + allowed origins locked in.
3. Integration
Relying party wires its sign-in surface to the four registration / authentication endpoints. The JS shim talks to the browser’s WebAuthn API; the backend talks to the validation server. Sandbox tenant available for testing before production credentials.
4. Production cutover
Production API keys issued. First user enrols. Admin console exposes credential enumeration, usage metering, audit log. Operator-side governance (rotation cadence, alert thresholds) applied.
Standards interoperability
The server speaks unmodified WebAuthn and CTAP2.1. Any compliant authenticator that passes the tenant’s AAGUID policy registers and authenticates. There is no vendor lock-in at the authenticator layer.
Existing IdP integration
SAML or OIDC for operator-admin login. SCIM for tenant-side user provisioning where the operator wants automated lifecycle. The server is the WebAuthn ceremony engine; identity-data ownership stays in the operator’s existing IdP.
Where this fits in the bigger picture.
Product: OnePass Card
A FIDO2 authenticator the validation server is purpose-built to verify.
Product: FIDO2 Nano-Card Applet
embedded secure-element FIDO2 authenticator the server verifies natively.
Solution: Passwordless MFA
Why the validation server is the deployable end of the FIDO story.
Technology: WebAuthn
How the JS API and REST endpoints map to the spec.
Blog: embedded secure-element FIDO2
End-to-end deployment story for SIM-shaped authenticators against this server.
Blog: Attestation objects
The format the server verifies on every registration.
Want a working FIDO validation server in a fortnight?
Drop us a note with your tenant scope, target authenticators, and integration language. We can usually have a sandbox up in a few business days.