Cloudflare Workers Passkey: 0$ Auth-Infrastruktur

Boomerang des Servicewachstums: Die Auth-SaaS-Rechnungsbombe

Wenn Start-ups und einzelne Entwicklerteams einen neuen Dienst auf den Markt bringen, gehört eine externe Auth-SaaS (Software as a Service) wie Auth0, Clerk, Firebase Auth oder Firebase Authentication oft zu den ersten Komponenten, die sie integrieren.

Es ist die beste Wahl, um das Risiko einer eigenen Implementierung von Passwort-Verschlüsselung, Social Logins (Google, Apple) und MFA (Multi-Faktor-Authentifizierung) zu vermeiden und schnell einen Prototyp zu starten. Sobald der Dienst jedoch wächst und die Zahl der monatlich aktiven Nutzer (MAU) 10.000 oder 100.000 überschreitet, kehrt die Auth-SaaS als gefürchtete „Cloud-Kostenbombe“ zurück.

[Gängige Auth-SaaS-Kostenstruktur (Stand 2026)]
- Auth0: B2C Pro Plan Basis $23/Monat + $0.07 pro Nutzer über 10.000 MAU (bei 100.000 MAU $6.300+/Monat)
- Clerk: Pro Plan Basis $25/Monat + $0.02 pro Nutzer über 10.000 MAU (bei 100.000 MAU $1.800+/Monat)
- Firebase Auth: $0.01~$0.06 pro Vorgang für Phone Auth und SMS-Infrastruktur
---------------------------------------------------------------------
Ergebnis: Ein schwerwiegendes strukturelles Problem, bei dem die Marge pro Nutzer sinkt, je mehr Registrierungen erfolgen

Ein noch schwerwiegenderes Problem besteht darin, dass bei jedem Benutzer-Login ein Hin- und Rückweg zu externen Auth-SaaS-Servern (gehostet in den USA oder Osteuropa) stattfindet, was 100ms~300ms oder mehr an Netzwerk-Latenzzeit (RTT) hinzufügt und die initiale Ladezeit der Anwendung verlangsamt.

Im modernen Web- und Mobil-Ökosystem von 2026 ist die passwortlose Passkey (WebAuthn / FIDO2)-Authentifizierung auf Basis von Fingerabdruck/FaceID als Standard etabliert. Durch die Kombination der Edge-Serverless-Laufzeitumgebung von Cloudflare Workers mit der Web Crypto API (crypto.subtle) können Sie ein Nächste-Generation-Authentifizierungssystem mit einer Latenzzeit von unter 5ms weltweit und $0 Infrastrukturkosten aufbauen, ohne auch nur einen einzigen Dollar an externe Auth-SaaS-Anbieter zu zahlen.

In diesem Artikel behandeln wir umfassend alles von den Abrechnungsgrenzen von Auth-SaaS über die internen Funktionsprinzipien der Passkey (WebAuthn)-Authentifizierungspipeline, den praktischen Code zur Integration von Cloudflare Workers + KV + D1 + Web Crypto bis hin zu Sicherheitsvalidierungsmodulen.

Architekturvergleich: Auth SaaS vs. Cloudflare Native Passkey

Funktionsprinzip von Passkey (WebAuthn): Challenge-basierte Public-Key-Kryptographie

Passkey nutzt den Sicherheitschip (Secure Enclave) auf den Geräten der Nutzer (iPhone, Android, Mac, Windows). Anstatt Passwörter zu speichern, bewahrt der Server lediglich den öffentlichen Schlüssel (Public Key) des Nutzers in der Datenbank (Cloudflare D1) auf.

+-----------------------------------------------------------------------------------+
| Passkey (WebAuthn) Login-Ablauf                                                   |
+-----------------------------------------------------------------------------------+

[Nutzer (Fingerabdruck/FaceID)] [Cloudflare Workers Edge]         [Cloudflare D1 DB]
         |                              |                                |
         |--- 1. Login-Anfrage -------->|                                |
         |                              |--- 2. Zufällige Challenge ----->| (Workers KV Speicherung)
         |<-- 3. Challenge zurück ------|     generieren                 |
         |                              |                                |
 (Sicherheitschip signiert Challenge)   |                                |
         |                              |                                |
         |--- 4. Signatur (Signature) ->|                                |
         |       übermitteln            |--- 5. Gespeicherten Public --->|
         |                              |       Key abfragen             |
         |                              |--- 6. Web Crypto Signatur-     |
         |                              |       Verifizierung            |
         |<-- 7. Auth erfolgreich ------|                                |
         |       (JWT ausstellen)       |                                |

1. Challenge-Ausstellung: Der Server generiert eine zufällige Challenge und speichert sie für 2 Minuten gültig in Workers KV.
2. Gerätesignatur: Sobald der Nutzer sich per Fingerabdruck oder FaceID authentifiziert hat, signiert der Private Key des Geräts die Challenge.
3. Web Crypto Signatur-Verifizierung: Der Server prüft mit crypto.subtle.verify() und dem in D1 gespeicherten Public Key des Nutzers, ob die Signatur gültig ist.
4. JWT-Sitzungsausstellung: Nach erfolgreicher Verifizierung wird ein HTTP-Only Cookie oder ein Bearer JWT Token ausgestellt.

Bei all diesen Schritten werden keinerlei Passwörter oder sensible Informationen über das Netzwerk übertragen.

Schritt 1: Speicherdesign (Cloudflare D1 + Workers KV)

Für die Passkey-Authentifizierung werden zwei Speicherebenen verwendet:

• Workers KV: Zur Aufbewahrung von Einmallevel-Login-Challenges, die nach 2 Minuten automatisch ablaufen (TTL) (ultraschnelles Lesen/Schreiben)
• Cloudflare D1 (SQLite): Zur dauerhaften Speicherung von Benutzerkontoinformationen und Passkey-Public-Keys (Credential ID, Public Key, Sign Counter)

D1-Datenbankschema (schema.sql)

-- D1 Database Schema: schema.sql

-- Benutzer-Tabelle
CREATE TABLE IF NOT EXISTS users (
    id TEXT PRIMARY KEY,
    email TEXT NOT NULL UNIQUE,
    name TEXT NOT NULL,
    created_at INTEGER NOT NULL
);

-- Passkey-Credentials-Tabelle
CREATE TABLE IF NOT EXISTS passkey_credentials (
    id TEXT PRIMARY KEY,               -- Credential ID (Base64URL)
    user_id TEXT NOT NULL,
    public_key TEXT NOT NULL,          -- COSE / WebCrypto-kompatibler Public Key (Base64)
    counter INTEGER NOT NULL DEFAULT 0,-- Signatur-Zähler zum Schutz vor Klon-Angriffen
    transports TEXT,                   -- 'internal', 'hybrid', 'ble' etc.
    created_at INTEGER NOT NULL,
    FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE
);

CREATE INDEX IF NOT EXISTS idx_credentials_user_id ON passkey_credentials(user_id);

wrangler.jsonc-Bindings hinzufügen:

// wrangler.jsonc
{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "edge-passkey-auth",
  "main": "src/index.ts",
  "compatibility_date": "2026-01-01",
  "compatibility_flags": ["nodejs_compat"],

  // 1. KV für temporäre Challenge-Speicherung
  "kv_namespaces": [
    {
      "binding": "AUTH_KV",
      "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    }
  ],

  // 2. D1 für dauerhafte Benutzer- und Public-Key-Speicherung
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "passkey_db",
      "database_id": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
    }
  ]
}

Schritt 2: Web Crypto API und Passkey-Backend-Implementierung (Hono.js)

Durch die Kombination der Community-Standardbibliothek SimpleWebAuthn mit Cloudflares nativem crypto.subtle erstellen wir ein leichtgewichtiges Backend.

Paketinstallation

npm install hono @simplewebauthn/server jose

Serverless Auth-API-Server (src/index.ts)

// src/index.ts
import { Hono } from "hono";
import { cors } from "hono/cors";
import {
  generateRegistrationOptions,
  verifyRegistrationResponse,
  generateAuthenticationOptions,
  verifyAuthenticationResponse,
} from "@simplewebauthn/server";
import { SignJWT, jwtVerify } from "jose";

type Env = {
  Bindings: {
    AUTH_KV: KVNamespace;
    DB: D1Database;
    JWT_SECRET: string;
  };
};

const app = new Hono<Env>();

app.use("*", cors({ origin: "*", credentials: true }));

const RP_NAME = "EffiDev App";
const RP_ID = "effidev.dev"; // Tatsächliche Produktionsdomain
const ORIGIN = `https://${RP_ID}`;

// -------------------------------------------------------------------
// 1. Passkey-Registrierung (Registrierung/Gerät hinzufügen) - Schritt 1: Challenge generieren
// -------------------------------------------------------------------
app.post("/api/auth/register/options", async (c) => {
  const { email, name } = await c.req.json();

  // Nutzer in D1 abfragen oder temporär erstellen
  let user = await c.env.DB.prepare("SELECT * FROM users WHERE email = ?").bind(email).first();
  const userId = user ? (user.id as string) : crypto.randomUUID();

  if (!user) {
    await c.env.DB.prepare(
      "INSERT INTO users (id, email, name, created_at) VALUES (?, ?, ?, ?)"
    ).bind(userId, email, name, Date.now()).run();
  }

  // Bereits registrierte Passkeys abfragen
  const credentials = await c.env.DB.prepare(
    "SELECT id FROM passkey_credentials WHERE user_id = ?"
  ).bind(userId).all();

  const excludeCredentials = credentials.results.map((cred) => ({
    id: cred.id as string,
    transports: ["internal" as const, "hybrid" as const],
  }));

  // WebAuthn-Registrierungsoptionen erstellen
  const options = await generateRegistrationOptions({
    rpName: RP_NAME,
    rpID: RP_ID,
    userID: new TextEncoder().encode(userId),
    userName: email,
    userDisplayName: name,
    attestationType: "none",
    excludeCredentials,
    authenticatorSelection: {
      residentKey: "required",
      userVerification: "preferred",
    },
  });

  // Challenge in KV speichern (TTL: 2 Minuten)
  await c.env.AUTH_KV.put(`reg_challenge:${userId}`, options.challenge, { expirationTtl: 120 });

  return c.json({ options, userId });
});

// -------------------------------------------------------------------
// 2. Passkey-Registrierung - Schritt 2: Gerätesignatur verifizieren & Public Key in D1 speichern
// -------------------------------------------------------------------
app.post("/api/auth/register/verify", async (c) => {
  const { userId, response } = await c.req.json();

  const expectedChallenge = await c.env.AUTH_KV.get(`reg_challenge:${userId}`);
  if (!expectedChallenge) {
    return c.json({ error: "Challenge expired or invalid" }, 400);
  }

  // Challenge sofort verwerfen
  await c.env.AUTH_KV.delete(`reg_challenge:${userId}`);

  const verification = await verifyRegistrationResponse({
    response,
    expectedChallenge,
    expectedOrigin: ORIGIN,
    expectedRPID: RP_ID,
  });

  if (!verification.verified || !verification.registrationInfo) {
    return c.json({ error: "Registration verification failed" }, 400);
  }

  const { credential } = verification.registrationInfo;

  // Public Key in D1 speichern (Base64-Kodierung)
  await c.env.DB.prepare(
    `INSERT INTO passkey_credentials (id, user_id, public_key, counter, created_at)
     VALUES (?, ?, ?, ?, ?)`
  ).bind(
    credential.id,
    userId,
    Buffer.from(credential.publicKey).toString("base64"),
    credential.counter,
    Date.now()
  ).run();

  return c.json({ success: true, message: "Passkey registered successfully" });
});

// -------------------------------------------------------------------
// 3. Passkey Login - Schritt 1: Challenge-Ausstellung
// -------------------------------------------------------------------
app.post("/api/auth/login/options", async (c) => {
  const options = await generateAuthenticationOptions({
    rpID: RP_ID,
    userVerification: "preferred",
  });

  const sessionChallengeId = crypto.randomUUID();
  await c.env.AUTH_KV.put(`auth_challenge:${sessionChallengeId}`, options.challenge, { expirationTtl: 120 });

  return c.json({ options, sessionChallengeId });
});

// -------------------------------------------------------------------
// 4. Passkey Login - Schritt 2: Signatur verifizieren & ultraschnelle JWT-Ausstellung
// -------------------------------------------------------------------
app.post("/api/auth/login/verify", async (c) => {
  const { sessionChallengeId, response } = await c.req.json();

  const expectedChallenge = await c.env.AUTH_KV.get(`auth_challenge:${sessionChallengeId}`);
  if (!expectedChallenge) {
    return c.json({ error: "Challenge expired" }, 400);
  }
  await c.env.AUTH_KV.delete(`auth_challenge:${sessionChallengeId}`);

  // Gespeicherte Passkey-Credential in D1 abfragen
  const credRecord = await c.env.DB.prepare(
    "SELECT * FROM passkey_credentials WHERE id = ?"
  ).bind(response.id).first();

  if (!credRecord) {
    return c.json({ error: "Passkey not found" }, 404);
  }

  const publicKey = new Uint8Array(Buffer.from(credRecord.public_key as string, "base64"));

  // Signatur verifizieren
  const verification = await verifyAuthenticationResponse({
    response,
    expectedChallenge,
    expectedOrigin: ORIGIN,
    expectedRPID: RP_ID,
    credential: {
      id: credRecord.id as string,
      publicKey,
      counter: credRecord.counter as number,
    },
  });

  if (!verification.verified) {
    return c.json({ error: "Invalid signature" }, 401);
  }

  // Counter zur Verhinderung von Klon-Angriffen aktualisieren
  await c.env.DB.prepare(
    "UPDATE passkey_credentials SET counter = ? WHERE id = ?"
  ).bind(verification.authenticationInfo.newCounter, credRecord.id).run();

  // Ultraschnelle JWT-Ausstellung unter 5ms (unter Nutzung von jose mit Web Crypto)
  const secret = new TextEncoder().encode(c.env.JWT_SECRET || "fallback-secret-key-32-chars-min");
  const token = await new SignJWT({ userId: credRecord.user_id, role: "user" })
    .setProtectedHeader({ alg: "HS256" })
    .setIssuedAt()
    .setExpirationTime("7d")
    .sign(secret);

  return c.json({ success: true, token });
});

export default app;

Schritt 3: Frontend-Integration (Web / Flutter)

Web-Browser-Integrationscode

Unter Verwendung des Browser-Standardpakets @simplewebauthn/browser wird das Pop-up für die Fingerabdruck-/FaceID-Authentifizierung mit einer einzigen Zeile aufgerufen.

import { startRegistration, startAuthentication } from "@simplewebauthn/browser";

// 1. Passkey-Registrierung
async function registerPasskey(email, name) {
  const optRes = await fetch("/api/auth/register/options", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ email, name }),
  });
  const { options, userId } = await optRes.json();

  // Pop-up für biometrische Fingerabdruck-/FaceID-Authentifizierung des Browsers auslösen
  const attResp = await startRegistration(options);

  const verifyRes = await fetch("/api/auth/register/verify", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ userId, response: attResp }),
  });

  return await verifyRes.json();
}

// 2. Einfacher Passkey-Login in 1 Sekunde
async function loginWithPasskey() {
  const optRes = await fetch("/api/auth/login/options", { method: "POST" });
  const { options, sessionChallengeId } = await optRes.json();

  // Biometrische Authentifizierung durchführen
  const asseResp = await startAuthentication(options);

  const verifyRes = await fetch("/api/auth/login/verify", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ sessionChallengeId, response: asseResp }),
  });

  const { token } = await verifyRes.json();
  localStorage.setItem("access_token", token);
}

Benchmark- und Kostenreduzierungsbericht

Basierend auf einem Mobil-/Webdienst mit 100.000 MAU (monatlich aktiven Nutzern) zeigt das folgende Vergleichsergebnis die Kosten- und Leistungsmetriken des Cloudflare Native Passkey-Systems im Vergleich zu traditionellen Auth0/Clerk-SaaS-Diensten.

Kosten- und Leistungsvergleichstabelle

Unter Nutzung des kostenlosen Tarifs von Cloudflare Workers (100.000 Anfragen/Tag) sowie des Paid-Tarifs ($5/Monat für 10 Millionen Anfragen) können Sie die Auth-SaaS-Kosten von über 6.000 USD pro Monat zu 100 % einsparen.

Fazit: Unabhängige Serverless-Sicherheitsarchitektur im Jahr 2026

Externe Auth-SaaS sind bei der Entwicklung von ersten Prototypen nützlich, werden jedoch zu einer enormen Kostenbelastung, die die Marge des Unternehmens schmälert, sobald der Dienst richtig an Fahrt gewinnt.

Die Kombination aus Cloudflare Workers und Passkey (WebAuthn) bietet die folgenden Sicherheitsvorteile der nächsten Generation:

1. $0-Kosten-Pipeline: Vollständige Eliminierung steiler SaaS-Gebührenbomben bei steigenden MAU
2. Ultraschnelle Antwortzeit von unter 5ms: Direkte Verifizierung in über 300 Edge-Rechenzentren weltweit ohne Hin- und Rückwege zu externen Servern
3. Perfekte Sicherheit: Das Passwort selbst existiert nicht mehr, und Angriffe werden durch Web Crypto API und Sicherheitschip-basierte Verfahren vollständig abgewehrt
4. Sicherung des Dateneigentums: Benutzerkonten- und Public-Key-Daten werden sicher in SQLite D1 aufbewahrt, was Vendor Lock-in verhindert

Anstatt jeden Monat Rechnungen an externe Authentifizierungsdienste zu zahlen, sollten Sie eine Cloudflare Edge-native Passkey-Authentifizierungspipeline aufbauen, um gleichzeitig ein Höchstmaß an UX und Infrastruktureffizienz zu erreichen.

Ähnlicher Artikel: Im Leitfaden Drizzle ORM + Cloudflare D1: 99 % Bundle-Reduktion mit Edge-SQLite-Architektur erfahren Sie auch, wie Sie ein Edge-Datenbankschema aufbauen.