En el ecosistema JavaScript llevan años apareciendo librerías para “hacer login” dentro de una app concreta, y también han triunfado plataformas SaaS tipo Auth0 o Clerk para centralizar identidad sin montar infraestructura propia. OpenAuth (proyecto de anomalyco/openauth) intenta ocupar el hueco intermedio: un servidor de autenticación centralizado, autoalojado y basado en estándares (OAuth 2.0), pensado para que lo despliegues donde ya corre tu stack.
La idea es simple: en vez de acoplar la autenticación a cada aplicación, levantas un issuer (emisor) que gestiona flujos OAuth y entrega tokens de acceso y refresh a cualquier cliente compatible (web, móvil, SPA, APIs o clientes de terceros). El repositorio deja claro que está en beta, así que el atractivo viene con la advertencia habitual: potencia y velocidad de adopción, sí; madurez “enterprise”, todavía por demostrar.
Qué lo hace diferente (según su planteamiento)
1) Centralizado, pero sin SaaS
OpenAuth se plantea como un “auth server” que corre en tu infraestructura: Node.js, Bun, AWS Lambda o Cloudflare Workers. Puedes desplegarlo como servicio independiente o embebido dentro de una aplicación existente.
2) Estándares primero
Se apoya en OAuth 2.0 para que “cualquier cosa que hable OAuth” pueda autenticarse. Esto también abre la puerta a escenarios tipo “Login with myapp” (emitir credenciales para terceros), algo que muchas soluciones caseras no hacen bien.
3) Minimalismo consciente: no “resuelve” el user management
Una decisión poco común: no intenta abstraer tu base de datos de usuarios. Tras autenticarse el usuario (por GitHub, password, etc.), OpenAuth llama a un callback (success) y ahí tú decides: buscar usuario, crearlo, asociarlo a un workspace, etc. Es deliberado: evita imponer ORM, drivers o modelos de datos.
4) Estado mínimo y almacenamiento en KV
Aunque busca ser “casi stateless”, necesita guardar hashes de password, refresh tokens y poco más. La idea es que sea un KV store con implementaciones para sistemas “cero fricción” tipo Cloudflare KV o DynamoDB (y un MemoryStore para pruebas).
5) UI opcional y themeable
Incluye una UI lista para usar, personalizable, o puedes desactivarla y montar la tuya.
Cómo se compone una instalación “típica”
- Issuer: una app (basada en Hono) que expone endpoints OAuth estándar (por ejemplo
/.well-known/oauth-authorization-server). - Providers: conectores para identidad (GitHub, password, pin code u otros).
- Subjects: el “molde” de lo que irá dentro del JWT (por ejemplo
userID,workspaceID), validado con un esquema (en el ejemplo usan valibot). - Success callback: punto donde “aterriza” la identidad en tu dominio (crear/lookup del usuario).
- Storage: KV para persistir lo mínimo indispensable.
Tabla rápida: lo que ganas y lo que sacrificas
| Aspecto | Qué aporta OpenAuth | El peaje |
|---|---|---|
| Control / soberanía | Autoalojado, corre en tu infra | Tú operas, tú monitorizas, tú respondes incidentes |
| Compatibilidad | OAuth 2.0 → clientes estándar | Hay que diseñar bien scopes, tokens, rotación |
| Flexibilidad de datos | No impone “users DB” | Tienes que implementar tu lógica de usuarios |
| Despliegue moderno | Node/Bun/Lambda/Workers | Complejidad según plataforma (secretos, KV, redes) |
| UI de login | UI lista, themeable | Si personalizas mucho, acabas manteniendo front propio |
Puntos de seguridad que conviene tomarse en serio (especialmente en beta)
- Refresh tokens: almacénalos y protégelos como oro. Si hay fuga, hay sesión persistente.
- Cookies vs localStorage: para SSR, cookies HttpOnly + Secure suelen ser la opción más sólida. En SPA, si guardas tokens en
localStorage, asume riesgo mayor ante XSS. - PKCE en clientes públicos: imprescindible en SPA/móvil (y el repo lo plantea así).
- Rate limiting / anti-abuse: password provider implica flujos sensibles (fuerza bruta, enumeración de usuarios, “forgot password”…).
- Rotación de claves y configuración: define políticas claras para expiración de tokens, revocación y rotación de secretos.
- Auditoría y logs: centraliza trazas de auth (sin volcar datos sensibles) y prepara alertas.
¿Para quién tiene sentido?
- Equipos que quieren un servidor de autenticación común para varias apps (web interna, admin tools, APIs, móvil).
- Proyectos que no quieren SaaS por coste, compliance o control (o que quieren evitar el “lock-in”).
- Organizaciones que ya trabajan cómodo con Cloudflare/AWS y prefieren un componente más en su infraestructura.
¿Cuándo miraría otra cosa?
- Si necesitas un IAM completo con administración de usuarios, roles complejos, paneles, flujos corporativos y mucha madurez “enterprise” desde el día 1.
- Si tu prioridad es “cero operación”: ahí el SaaS sigue ganando por inercia (a costa de control y coste).
