Implementando Better Auth: Autenticación y autorización en TypeScript

Ideas clave

• Better Auth es agnóstico al framework y está diseñado para TypeScript, con un núcleo minimalista extensible mediante plugins.
• Se puede self-hostear y ofrece control total sobre datos, esquemas y tipado end‑to‑end.
• Integración recomendada en Angular mediante servicio inyectable + HttpInterceptor; ejemplos y patrones operativos incluidos.
• Casos de uso: B2B SaaS, cumplimiento (GDPR/HIPAA), integraciones con agentes/workflows como n8n.
• Self‑hosting implica responsabilidades operativas: seguridad, observabilidad, backups y pruebas.

Better Auth es un framework de autenticación y autorización universal e independiente del framework para TypeScript — arquitectura y ventajas

Decisiones técnicas clave

Better Auth se sostiene en dos decisiones técnicas clave:

• Implementar la lógica sobre APIs web estándar (Request/Response), lo que permite ejecutarlo en Node, Bun, Deno o entornos Edge.
• Diseñar un núcleo minimalista extensible mediante plugins, para evitar bloat y cargar solo lo que tu producto necesita.

Qué trae de serie

Qué trae de serie: email/password, 35+ proveedores OAuth, gestión de organizaciones (multi-tenant), sesiones múltiples, API keys, JWT, Magic Links y adaptadores para ORMs populares. Plugins oficiales cubren 2FA (TOTP), Passkeys/WebAuthn, SAML/OIDC para SSO y SCIM para provisioning.

Ventaja práctica

Ventaja práctica: control total de datos y schemas, tipado TypeScript end‑to‑end y la opción de self‑host sin vendor lock‑in. URL de referencia: better-auth.com

Integración en Angular: patrón recomendado (servicio + interceptor)

Para una app Angular enterprise, el patrón recomendable plantea un cliente agnóstico envuelto en un servicio inyectable y un HttpInterceptor para gestionar tokens/refresh.

Ejemplo mínimo

import { createAuthClient } from '@better-auth/client';
import { Injectable, signal } from '@angular/core';

const authClient = createAuthClient({ baseURL: '/api/auth' });

@Injectable({ providedIn: 'root' })
export class AuthService {
  public user = signal(null);

  async login(email: string, pass: string) {
    const { data, error } = await authClient.signIn.email({ email, password: pass });
    if (!error) this.user.set(data.user);
  }

  async logout() {
    await authClient.signOut();
    this.user.set(null);
  }
}

Complementa con

• HttpInterceptor que adjunte cookies o auth headers y maneje refresh tokens.
• Guards/Resolvers para rutas protegidas.
• Estado reactivo con Signals o RxJS para sincronizar UI.

Casos de uso y adopción incremental

Dónde aporta más valor

• B2B SaaS con orgs, roles y SSO: evita el “SSO tax”.
• Entornos con requisitos de cumplimiento (GDPR/HIPAA) que exigen soberanía de datos.
• Plataformas que integran agentes o workflows (better-auth.com) y requieren control granular de tokens.

Estrategia de incorporación

1. Prototipa con un subdominio /auth y un DB separado.
2. Migración gradual: dual‑write (nuevo sistema + migración batch) y pruebas canary.
3. Mide: tiempo de login, tasa de errores, coste infra y reducción de vendor fees.

Riesgos, operaciones y hardening

Puntos críticos

Self‑hosting devuelve responsabilidad al equipo. Puntos críticos:

• Seguridad operativa: rotación de claves, gestión de secrets, WAF y rate limiting.
• Tests y CI deterministas: flaky tests paralizan SSO/flows en producción.
• Observabilidad: logs estructurados, métricas de sesiones, alertas por anomalías.
• Backups y recovery para la DB de identidad.

Recomendaciones prácticas

• Least privilege para tokens de agente; scope limitado.
• Auditoría obligatoria de cambios críticos (SSO config, SCIM).
• Sandboxes para agentes que necesiten credenciales (no exponer prod keys).

Comparativa rápida contra alternativas

• Auth0 / Clerk (SaaS): rápido de arrancar, pero coste y lock‑in crecen con MAU y features empresariales.
• Auth.js/NextAuth: buena para apps ligadas a frameworks, menos agnóstico.
• Better Auth: mejor trade‑off para equipos TypeScript que quieren control, tipado y extensibilidad.

Criterio final: cuándo optar por Better Auth

Adopta Better Auth si:

• Tu stack es TypeScript-centric y necesitas independencia de framework.
• Buscas construir capacidades enterprise (SSO, SCIM) sin tarifas SaaS.
• Tienes equipo capaz de gestionar seguridad infra y operaciones.

No lo elijas si:

• Tu prioridad es lanzar un MVP sin recursos infra (en cuyo caso un SaaS puede ser válido).
• Tu infra actual no puede garantizar entornos deterministas y recuperación rápida.
• Tu backend principal no es compatible con JS/TS y migrar es inviable.

Better Auth no es la solución más simple, pero sí la más controlada para equipos que valoran soberanía, tipado y extensibilidad. Si tu objetivo es controlar la identidad (no cederla), empezar con npx auth init y una integración Angular mínima te dará una base sólida para escalar hacia SSO, 2FA y modelos multi‑tenant sin vender la llave del reino. Referencia: better-auth.com.

Dominicode Labs

Para equipos que trabajan con agentes, workflows o integraciones y buscan plantillas operativas y pruebas de concepto, puede ser útil revisar recursos y experimentos relacionados en Dominicode Labs. Estos recursos complementan prácticas de adopción incremental, testing y operación para infra de identidad.

FAQ

1. ¿Qué es Better Auth y para qué sirve?
2. ¿Se puede usar Better Auth con Angular?
3. ¿Qué funcionalidades trae por defecto?
4. ¿Cuáles son los riesgos de self‑hosting?
5. ¿Cuándo debería elegir un SaaS en lugar de Better Auth?
6. ¿Cómo empezar una migración incremental?