Is Locke Gateway really free?

Yes, completely. There's no per-user pricing, no authentication rate limits, and no premium tier. Gateway runs on a single AWS instance, and self-hosting the entire stack costs about $14/month.

How does the end-to-end encrypted vault work?

The WebAuthn PRF extension derives a secret on the authenticator hardware, which is fed through HKDF-SHA-256 to produce an AES-256-GCM encryption key. All encryption happens client-side. Gateway only stores encrypted blobs and HMAC-blinded key names, so even a server compromise yields only ciphertext.

Open Source + Free Auth Server

Passkey auth with zero server configuration.

Name: Locke Gateway
Brand: Locke

Locke Gateway is a free, multi-tenant passkey server. Point your frontend to gateway.locke.id and get WebAuthn registration, authentication, session management, and an end-to-end encrypted key-value store.

Built on open-passkey, our open-source passkey library for 6 languages and 20+ frameworks.

verified No API Keys | verified E2E Encrypted Vault | verified Post-Quantum Ready

Try Gateway arrow_forward View on GitHub

Quickstart

This is the entire setup

$ npm install @open-passkey/sdk

import { PasskeyClient } from "@open-passkey/sdk";

const passkey = new PasskeyClient({
  provider: "locke-gateway",
  rpId: "your-domain.com"
});

await passkey.register("user-id", "user@example.com");
await passkey.authenticate("user-id");

Framework packages for React, Vue, Angular, Svelte, and SolidJS.

What You Get

Authentication, storage, and data ownership

fingerprint

Passkey Auth

WebAuthn registration, authentication, and session management with instant revocation.

enhanced_encryption

E2E Encrypted Vault

Key-value store encrypted with AES-256-GCM with keys derived on-device via WebAuthn PRF extension.

dns

Public Key Export

Verify domain ownership via DNS TXT record, then you can export all public keys for your domain.

security

Post-Quantum Ready

ML-DSA-65-ES256 hybrid signatures. ES256 today, automatic upgrade to post-quantum when browsers support it.

domain_verification

Automatic Domain Scoping

No registration, no API keys, no shared namespaces. Credentials isolated by RP ID and domain validated from HTTP origin.

shield

Rate Limiting + DoS

Per-IP and per-RP rate limiting, request timeouts, max payload enforcement built into our free hosted instance.

Data Ownership

Export all public keys for your domain if it's time to self-host.

Gateway stores passkey credentials on your behalf, but they belong to you. Add a DNS TXT record to verify domain ownership, then export the full set of public keys associated with your RP ID.

This means you can migrate to a self-hosted backend at any time with a complete credential export. If you leave Gateway, your users keep their passkeys but not their sessions.

check DNS TXT record verification (standard ACME-style challenge)
check Export public keys, credential IDs, and metadata per domain
check Import into any WebAuthn-compliant relying party
check Private keys never leave the user's authenticator

# 1. Request a verification token
GET /passkey/domain/verify?domain=myapp.com
# Returns: { "txt_record": "locke-verify=abc123..." }

# 2. Add TXT record to your DNS
_locke-verify.myapp.com TXT "locke-verify=abc123..."

# 3. Confirm and export
POST /passkey/domain/confirm
GET /passkey/domain/export?domain=myapp.com

# Returns all public keys, credential IDs,
# sign counts, and user handles for your domain

const vault = passkey.vault();

await vault.setItem("api-key", "sk_live_...");
const key = await vault.getItem("api-key");

// Persist encryption key across page reloads
await vault.persistKey();

// Restore on next visit
await Vault.restore("/passkey");

Encrypted Storage

E2E encrypted key-value store

Like localStorage, but server-backed and encrypted before it leaves the browser. The encryption key is derived from the WebAuthn PRF extension, run through HKDF-SHA-256, then used for AES-256-GCM encryption with random IVs per write.

Key names are HMAC-blinded for deterministic lookup without revealing contents. The server cannot read your keys or values. Symmetric primitives only, so vault encryption is already quantum-safe.

How Gateway Compares

Feature	Auth0 / Clerk	Self-Built	Gateway
Setup time	~30 min	Hours/Days	~2 seconds
Server required	check	check	cloud
Free tier limits	MAU caps	Infra cost	None
E2E encrypted storage	close	DIY	check
Credential export	close	check	check
Post-quantum ready	close	close	check
Open source	close	check	check

Language & Framework Support

30+ packages. One protocol.

All 6 core implementations share 31 test vectors. Identical behavior regardless of stack.

Core Protocol

TypeScript Go Python Java .NET Rust

Frontend SDKs

React Vue Angular Svelte SolidJS Vanilla JS

Server Framework Bindings

Express Fastify Hono NestJS Next.js Nuxt SvelteKit Remix Astro Flask FastAPI Django Spring Boot ASP.NET Core Axum Gin Echo Chi Fiber net/http

Easily switch to your own backend and serve your own auth infrastructure.

The SDK accepts either provider: "locke-gateway" or baseUrl: "/passkey". Same client code, your infrastructure. open-passkey gives you server bindings for every major framework.

// Switch from Gateway to self-hosted
const passkey = new PasskeyClient({
  baseUrl: "/passkey"
});

Self-hosting costs ~$14/month on AWS (t4g.small + Postgres + Redis).

FAQ

Frequently Asked Questions

Is Gateway really free? expand_more

Yes, completely. There's no per-user pricing, no authentication rate limits, and no premium tier hiding behind the free plan. We built Gateway because passkey adoption needs to grow, and putting a price tag on authentication infrastructure works against that goal. It runs on a single AWS instance, and if you'd rather host it yourself, the entire stack runs for about $14/month on a t4g.small with Postgres and Redis.

How does the encrypted vault work? expand_more

When a user authenticates, the WebAuthn PRF extension evaluates HMAC(credentialSecret, salt) directly on the authenticator hardware. That 32-byte output gets fed through HKDF-SHA-256 to derive an AES-256-GCM encryption key. The important part is that all of this happens client-side. Gateway only ever sees encrypted blobs and HMAC-blinded key names, so even if someone compromised the server, they'd have ciphertext with no way to decrypt it.

How does public key export work? expand_more

First, you request a verification token from Gateway and publish it as a DNS TXT record at _locke-verify.yourdomain.com. Once Gateway confirms the record, you can export every public key, credential ID, sign count, and user handle associated with your RP ID. From there, you can import those credentials into any WebAuthn-compliant relying party. This is how you migrate off Gateway if you ever want to, and it's worth noting that private keys never leave the authenticator at any point in this process.

What does "post-quantum ready" mean? expand_more

open-passkey supports ML-DSA-65-ES256 hybrid signatures, which pair the NIST post-quantum standard (FIPS 204) with classical ECDSA P-256. Today, browsers negotiate ES256 because that's what they support. When post-quantum WebAuthn lands in browsers, credentials registered through open-passkey will upgrade automatically without any changes on your end. As for vault encryption, it already uses AES-256-GCM, which is a symmetric cipher and inherently resistant to quantum attacks.

How is this different from using WebAuthn directly? expand_more

WebAuthn is a browser API that handles the cryptographic ceremony between the authenticator and the browser. But the API alone doesn't give you everything you need. You still have to build a server that stores credentials, issues challenges, verifies attestations, manages sessions, and handles all the edge cases around credential lifecycle. open-passkey wraps the full protocol into SDKs for both the client and server sides, so you get a complete implementation out of the box. And if you don't want to run a server at all, Gateway handles that part for you.