Deja que un sistema posea la identidad
El formulario de inicio recoge una petición. El sistema de autenticación decide si esa petición establece una identidad y emite la sesión en la que confía el resto de la aplicación. Mantener esa responsabilidad en un solo lugar evita que cada ruta invente su propia interpretación de un usuario conectado.
supastack compone Better Auth para identidad y gestión de sesiones. El código de aplicación resuelve la sesión en fronteras protegidas y la relaciona con un espacio de trabajo. La interfaz puede mostrar estados de acceso útiles, pero el estado de cliente no debe convertirse en prueba de que una operación está autorizada.
La regla debe valer en cada superficie que el producto entregue. Los clientes web, móvil y escritorio deberían consumir la misma decisión de identidad en lugar de implementarla tres veces — tres interpretaciones de «conectado» es de donde vienen los bugs de cuentas.
Elige los métodos de inicio de sesión con criterio
Cada método cambia fricción por superficie de ataque y una dependencia externa. Las contraseñas necesitan flujos de restablecimiento y limitación de ritmo. Los magic links y los códigos de un solo uso dependen de la entregabilidad del email. OAuth delega la identidad a proveedores como Google, GitHub o Apple — y hereda sus caídas, pantallas de consentimiento y reglas de callback.
supastack los compone a través de Better Auth — OTP por email, contraseña, magic link, OAuth, con dos factores y passkeys disponibles — detrás de una única decisión de identidad. Entrega el conjunto más pequeño que tu audiencia necesite de verdad; cada método adicional es otra ruta de callback, otro modo de fallo y otro flujo que verificar antes del lanzamiento. La guía de autenticación cubre el cableado.
Cuando una persona puede iniciar sesión de más de una forma, decide cómo se unen los métodos. Una cuenta de Google y un magic link de email que resuelven a la misma dirección deberían aterrizar en una sola identidad, no en dos. Las reglas de vinculación de cuentas son parte de la decisión de identidad, y equivocarlas crea usuarios duplicados que emergen meses después como datos misteriosamente desaparecidos.
Las sesiones son la credencial que importa
Tras el inicio de sesión, la sesión — no la contraseña — es lo que lleva cada petición. Su caducidad, almacenamiento y reglas de invalidación definen la postura de seguridad real. Una sesión que sobrevive al cierre de sesión, o una que un miembro expulsado del espacio puede seguir usando, es un fallo de autenticación que ninguna pantalla de login pulida puede arreglar.
Decide el ciclo de vida desde el principio: cuánto viven las sesiones, si los usuarios pueden ver y revocar sus sesiones activas, y qué les hace un cambio de contraseña, de email o una expulsión del espacio. La gestión de sesiones existe como módulo en el kit precisamente porque estas decisiones son fáciles de posponer y caras de reequipar.
Relaciona la sesión con el registro solicitado
Estar conectado no concede acceso a cada registro. Resuelve el espacio de trabajo del usuario en el servidor e incluye ese límite en lecturas y mutaciones. Un identificador de tarea o enlace de recuperación es una referencia al trabajo, no un permiso para recuperarlo — el post sobre fronteras de espacio cubre ese lado de la frontera en detalle.
Resuelve el ámbito en un orden fijo: autentica la sesión, carga la membresía, y después lee o escribe con ese contexto de espacio — nunca al revés. El middleware puede redirigir a un visitante anónimo, pero no puede autorizar la operación; la comprobación pertenece a la acción de servidor o al manejador de ruta donde se toca el registro.
Las cuentas tienen un ciclo de vida, no solo un principio
El aprovisionamiento es la primera prueba de esa frontera. Cuando un usuario se registra, el espacio de trabajo y los registros de propiedad que siguen deben poder crearse más de una vez sin riesgo — los hooks de ciclo de vida pueden repetirse por proveedores, reintentos o herramientas de soporte. Un evento duplicado debería ser una no-operación, no una organización duplicada.
El final del ciclo de vida merece el mismo cuidado. Los cambios de email, los restablecimientos de contraseña, la expulsión de miembros, el borrado de cuentas y la exportación de datos son cada uno pequeños flujos con sus propios casos de abuso — un enlace de restablecimiento que funciona dos veces, una exportación que filtra los registros de un compañero. supastack entrega exportación GDPR y gestión de sesiones por esta razón; sobre lo que sea que construyas, presupuesta los flujos aburridos.
Prueba el ciclo de vida, incluido su final
Un test de inicio de sesión exitoso es útil pero incompleto. Ejerce credenciales inválidas, códigos de verificación caducados o reutilizados, peticiones anónimas y acceso entre espacios. Verifica que cerrar sesión invalida la sesión y que un cliente que vuelve no puede seguir usando una pantalla previamente autorizada para trabajo protegido.
Distingue los tests de handler de la aceptación en despliegue. Un adaptador en memoria puede establecer la semántica de un handler de auth real sin demostrar la persistencia Postgres ni un callback de proveedor. Verifica el origin configurado, la ruta de callback, la restauración de sesión y el cierre con las dependencias desplegadas antes de afirmar que el flujo completo de inicio funciona.
- Las credenciales inválidas y los códigos de verificación caducados o reutilizados se rechazan.
- Las peticiones anónimas y entre espacios no reciben datos propios.
- El cierre de sesión invalida la sesión — un cliente obsoleto no puede seguir actuando.
- Los registros aprovisionados siguen siendo idempotentes cuando los hooks de ciclo de vida se repiten.
- Los callbacks de proveedores reales funcionan en el origin configurado — verificado, no supuesto.
Preguntas frecuentes de autenticación
Las preguntas de abajo emergen una vez terminado el formulario de inicio, cuando el sistema tiene que seguir funcionando.
- ¿Basta el middleware para proteger rutas? — El middleware es una redirección cómoda, no una capa de autorización. Cada acción de servidor y cada ruta resuelven la sesión y el espacio por sí mismas; los guardas de página ocultan pantallas sin autorizar operaciones.
- ¿Construir auth propio o usar una librería? — La semántica de sesiones rara vez es donde un SaaS se diferencia. Una librería mantenida como Better Auth tras límites de módulo claros te da primitivas probadas mientras mantiene en tu código las decisiones que importan — delimitado, ciclo de vida.
- ¿Cómo se relacionan las sesiones con los espacios de trabajo? — La sesión identifica a la persona; el espacio identifica los registros que puede tocar. Resuelve la membresía en el servidor en cada petición y nunca confíes en un ID de espacio que envíe el cliente.
- ¿Qué esperan los clientes B2B de la autenticación? — Espacios de equipo con roles, inicio de sesión OAuth, visibilidad y revocación de sesiones y un registro de auditoría. Los dos factores y las passkeys se esperan cada vez más para roles de administración.
- ¿Qué rompe la autenticación en producción? — Normalmente los bordes: una URL de callback que solo existe en local, un hook que aprovisiona dos veces, una sesión que sobrevive a una membresía. Prueba los finales de los flujos, no solo los comienzos.