Cloudflare Workers Passkey: Infraestructura Auth $0

El bumerán del crecimiento del servicio: La bomba de facturación de Auth SaaS

Uno de los primeros componentes que adoptan las startups y los equipos de desarrollo al lanzar un nuevo servicio es un SaaS (Software as a Service) de autenticación externo, como Auth0, Clerk, Firebase Auth o Firebase Authentication.

Es la mejor opción para evitar los riesgos de implementar manualmente el cifrado de contraseñas, el inicio de sesión social (Google, Apple) y MFA (autenticación multifactor), permitiendo lanzar prototipos rápidamente. Sin embargo, en el momento en que el servicio crece y los usuarios activos mensuales (MAU) superan los 10,000 o 100,000, el SaaS de Auth se convierte en la más temida “bomba de costos en la nube”.

[Estructura de costos común de Auth SaaS (A año 2026)]
- Auth0: B2C Pro Plan base $23/mes + $0.07 por usuario sobre 10,000 MAU ($6,300+/mes a 100,000 MAU)
- Clerk: Pro Plan base $25/mes + $0.02 por usuario sobre 10,000 MAU ($1,800+/mes a 100,000 MAU)
- Firebase Auth: $0.01~$0.06 por evento de Phone Auth e infraestructura SMS
---------------------------------------------------------------------
Resultado: Un problema estructural grave donde el margen por usuario disminuye a medida que aumentan los registros

Un problema aún más grave es que cada inicio de sesión requiere un viaje de ida y vuelta (RTT) a servidores externos de Auth SaaS (alojados en EE. UU. o Europa del Este), lo que añade más de 100ms~300ms de latencia de red y ralentiza la velocidad inicial de acceso a la aplicación.

En 2026, el ecosistema web y móvil moderno ha adoptado la autenticación sin contraseña basada en huellas dactilares/FaceID con Passkey (WebAuthn / FIDO2) como estándar. Además, combinando el entorno de ejecución edge serverless de Cloudflare Workers con la Web Crypto API (crypto.subtle), es posible construir directamente un sistema de autenticación de próxima generación con latencia menor a 5ms a nivel global y un costo de infraestructura de $0, sin pagar un solo dólar a un Auth SaaS externo.

En este artículo, abordaremos desde las limitaciones de facturación de los Auth SaaS hasta el funcionamiento interno del pipeline de autenticación Passkey (WebAuthn), código práctico de integración con Cloudflare Workers + KV + D1 + Web Crypto, y módulos de verificación de seguridad.

Comparación de arquitectura: Auth SaaS vs Cloudflare Native Passkey

Principio de funcionamiento de Passkey (WebAuthn): Criptografía de clave pública basada en desafíos

Passkey utiliza el chip de seguridad (Secure Enclave) integrado en los dispositivos del usuario (iPhone, Android, Mac, Windows). En lugar de almacenar contraseñas, el servidor conserva únicamente la clave pública (Public Key) del usuario en la base de datos (Cloudflare D1).

+-----------------------------------------------------------------------------------+
| Flujo de inicio de sesión con Passkey (WebAuthn)                                  |
+-----------------------------------------------------------------------------------+

[Usuario (Huella/FaceID)]   [Edge Cloudflare Workers]           [DB Cloudflare D1]
         |                              |                                |
         |--- 1. Solicitud de login --->|                                |
         |                              |--- 2. Generar Challenge aleatorio ->| (Guardado en Workers KV)
         |<-- 3. Retornar Challenge ----|                                |
         |                              |                                |
(Firma del challenge en chip seguro)    |                                |
         |                              |                                |
         |--- 4. Enviar Firma --------->|                                |
         |                              |--- 5. Consultar clave pública ->|
         |                              |--- 6. Verificación de firma Web Crypto
         |<-- 7. Éxito de Auth (JWT) ---|                                |

1. Emisión del Challenge: El servidor genera un desafío (Challenge) aleatorio y lo almacena en Workers KV con una validez de 2 minutos.
2. Firma del dispositivo: Una vez que el usuario confirma su identidad mediante huella dactilar o FaceID, el dispositivo firma el desafío con su clave privada (Private Key).
3. Verificación de firma con Web Crypto: El servidor verifica si la firma es válida utilizando crypto.subtle.verify() con la clave pública del usuario almacenada en D1.
4. Emisión de sesión JWT: Tras una verificación exitosa, se emite una Cookie HTTP-Only o un token Bearer JWT.

En todo este proceso, no se transmite ninguna contraseña ni información confidencial a través de la red.

Paso 1: Diseño de almacenamiento (Cloudflare D1 + Workers KV)

Para la autenticación con Passkey, se utilizan dos niveles de almacenamiento:

• Workers KV: Para almacenar desafíos de inicio de sesión de un solo uso que deben expirar automáticamente después de 2 minutos (TTL) (lectura y escritura de ultra alta velocidad).
• Cloudflare D1 (SQLite): Para el almacenamiento permanente de la información de la cuenta de usuario y las claves públicas de Passkey (Credential ID, Public Key, Sign Counter).

Esquema de base de datos D1 (schema.sql)

-- D1 Database Schema: schema.sql

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

-- Tabla de credenciales Passkey
CREATE TABLE IF NOT EXISTS passkey_credentials (
    id TEXT PRIMARY KEY,               -- Credential ID (Base64URL)
    user_id TEXT NOT NULL,
    public_key TEXT NOT NULL,          -- Clave pública compatible con COSE / WebCrypto (Base64)
    counter INTEGER NOT NULL DEFAULT 0,-- Contador de firmas para prevenir ataques de clonación
    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);

Añadir vinculación en wrangler.jsonc:

// 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 para almacenamiento temporal del challenge
  "kv_namespaces": [
    {
      "binding": "AUTH_KV",
      "id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    }
  ],

  // 2. D1 para almacenamiento permanente de usuarios y claves públicas
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "passkey_db",
      "database_id": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
    }
  ]
}

Paso 2: Implementación del backend para Web Crypto API y Passkey (Hono.js)

Construimos un backend ligero combinando la biblioteca estándar de la comunidad SimpleWebAuthn con el crypto.subtle nativo de Cloudflare.

Instalación de paquetes

npm install hono @simplewebauthn/server jose

Servidor API de autenticación serverless (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"; // Dominio de producción real
const ORIGIN = `https://${RP_ID}`;

// -------------------------------------------------------------------
// 1. Registro de Passkey (Registro / Añadir dispositivo) - Paso 1: Generar Challenge
// -------------------------------------------------------------------
app.post("/api/auth/register/options", async (c) => {
  const { email, name } = await c.req.json();

  // Consultar o crear usuario temporalmente en D1
  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();
  }

  // Consultar Passkeys previamente registradas
  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],
  }));

  // Generar opciones de registro WebAuthn
  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",
    },
  });

  // Almacenar challenge en KV (TTL: 2 minutos)
  await c.env.AUTH_KV.put(`reg_challenge:${userId}`, options.challenge, { expirationTtl: 120 });

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

// -------------------------------------------------------------------
// 2. Registro de Passkey - Paso 2: Verificación de firma del dispositivo y guardado en D1
// -------------------------------------------------------------------
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);
  }

  // Eliminar el challenge de inmediato
  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;

  // Guardar clave pública en D1 (Codificación Base64)
  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. Login con Passkey - Paso 1: Emisión de Challenge
// -------------------------------------------------------------------
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. Login con Passkey - Paso 2: Verificación de firma y emisión ultra rápida de JWT
// -------------------------------------------------------------------
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}`);

  // Consultar credencial Passkey almacenada en D1
  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"));

  // Verificación de firma
  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);
  }

  // Actualizar Counter para prevenir ataques de clonación
  await c.env.DB.prepare(
    "UPDATE passkey_credentials SET counter = ? WHERE id = ?"
  ).bind(verification.authenticationInfo.newCounter, credRecord.id).run();

  // Emisión ultra rápida de JWT en menos de 5ms (usando jose integrado con 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;

Paso 3: Integración con el Frontend (Web / Flutter)

Código de integración para navegador Web

Al utilizar el paquete estándar del navegador @simplewebauthn/browser, la ventana emergente de autenticación biométrica de Huella / FaceID se invoca con una sola línea de código.

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

// 1. Registro de Passkey
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();

  // Desencadenar la ventana emergente de autenticación biométrica Huella/FaceID del navegador
  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. Inicio de sesión rápido en 1 segundo con Passkey
async function loginWithPasskey() {
  const optRes = await fetch("/api/auth/login/options", { method: "POST" });
  const { options, sessionChallengeId } = await optRes.json();

  // Realizar autenticación biométrica
  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);
}

Reporte de benchmark y reducción de costos

A continuación se presenta la comparación de costo y métricas de rendimiento del sistema Cloudflare Native Passkey frente a los SaaS tradicionales de Auth0/Clerk, tomando como referencia un servicio móvil/web con 100,000 MAU (usuarios activos mensuales).

Tabla comparativa de costos y rendimiento

Al utilizar el plan gratuito de Cloudflare Workers (100,000 solicitudes diarias) y el plan Paid ($5/mes que incluye 10 millones de solicitudes), es posible ahorrar el 100% de los costos de Auth SaaS, los cuales superan los $6,000 USD mensuales.

Conclusión: Arquitectura de seguridad serverless independiente en 2026

Los Auth SaaS externos son útiles durante el desarrollo de prototipos iniciales, pero en el momento en que un servicio se consolida, se convierten en una enorme carga financiera que reduce los márgenes de la empresa.

La combinación de Cloudflare Workers y Passkey (WebAuthn) ofrece las siguientes ventajas de seguridad de próxima generación:

1. Pipeline de costo $0: Eliminación total de las bombas de comisiones SaaS a medida que aumenta el MAU.
2. Respuesta ultra rápida menor a 5ms: Verificación directa en más de 300 centros de datos edge en todo el mundo sin viajes de ida y vuelta a servidores externos.
3. Seguridad perfecta: No existen contraseñas, ofreciendo una defensa completa basada en Web Crypto API y chips de seguridad contra ataques.
4. Control total de los datos: La información de las cuentas de usuario y claves públicas se conserva de forma segura en SQLite D1, evitando la dependencia de proveedores (vendor lock-in).

En lugar de pagar facturas mensuales a servicios de autenticación externos, construya un pipeline de autenticación Passkey nativo en el edge de Cloudflare para lograr simultáneamente el máximo nivel de UX y eficiencia de infraestructura.

Artículo relacionado: Puede consultar la guía para construir esquemas de bases de datos edge en Drizzle ORM + Cloudflare D1: Arquitectura SQLite Edge con reducción del 99% en bundle.