For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /es/docs/web/authentication.md (or send Accept: text/markdown).
Autenticación
Métodos de acceso, sesiones y seguridad de la cuenta.
Crear y verificar una cuenta real
La autenticación significa demostrar quién está usando la aplicación. Inicie Postgres y ejecute las migraciones utilizando primero la guía de la base de datos, luego deje el servidor web en ejecución. Abra http://localhost:3000/auth,, elija el registro de correo electrónico/contraseña, ingrese su nombre, correo electrónico y contraseña, y envíe. Conserve EMAIL_PROVIDER=local para esta primera prueba.
Cuando un flujo solicita un código de correo electrónico, abra http://localhost:3000/mail-preview en otra pestaña del navegador, busque el mensaje más reciente para esa dirección y copie su código nuevamente en el formulario de inicio de sesión. Solicite un código nuevo si caduca. Estos mensajes permanecen en la bandeja de salida local; Al revisar repetidamente una bandeja de entrada externa no los encontrará. Cierre sesión y luego inicie sesión nuevamente para confirmar que la cuenta respaldada por la base de datos funciona.
Si el registro informa una conexión a la base de datos o un error de tabla faltante, finalice la configuración de la base de datos en lugar de habilitar el inicio de sesión social. Los botones de Google, GitHub, Apple, X y Microsoft necesitan su propia aplicación de proveedor y configuración de devolución de llamada; habilite uno solo después de que se complete la guía del proveedor. Better Auth es el motor predeterminado que se envía y no necesita una cuenta de autenticación paga para iniciar sesión en el correo electrónico local.
Elige los métodos de inicio de sesión habilitados
La base incluye correo electrónico y contraseña, OTP y autenticación social configurable. Better Auth gestiona la identidad y las sesiones, mientras que la aplicación compone la configuración del proveedor y la entrega transaccional de OTP.
Habilita solo los proveedores sociales que hayas configurado. Los secretos de cliente del proveedor y el secreto de autenticación se guardan únicamente en el servidor.
Conecta la identidad con un espacio de trabajo
Los controladores autenticados resuelven el estado de la sesión antes de acceder a los registros del espacio de trabajo. El aprovisionamiento del espacio debe ser idempotente para que repetir un hook del ciclo de vida no cree registros de propiedad duplicados.
Verifica el comportamiento de la sesión
Prueba el inicio de sesión, los OTP no válidos o caducados, el consumo de un solo uso, el cierre de sesión y el rechazo del acceso anónimo. Las pruebas con adaptador de memoria cubren la semántica de los controladores; la persistencia en la base de datos de producción y las devoluciones de llamada de proveedores reales requieren una aceptación independiente.
Configuración y ajustes
Better Auth es el motor por defecto (AUTH_PROVIDER=better-auth); hay un motor Auth.js disponible para equipos que se estandarizan en él. Los métodos habilitados se declaran por proveedor: email/contraseña, códigos de un solo uso entregados por correo transaccional y acceso social para Google, Apple, GitHub, Microsoft y Twitter.
Cada proveedor social se activa con su flag AUTH_<PROVIDER>_ENABLED más el client id y secret correspondientes. El secreto de autenticación, los secretos de proveedor y las claves de firma de sesión son configuración solo del servidor.
AUTH_PROVIDER=better-auth
AUTH_SECRET=generate-a-long-random-value
AUTH_GOOGLE_ENABLED=true
GOOGLE_CLIENT_ID=…
GOOGLE_CLIENT_SECRET=…Flujo de implementación
La superficie /auth renderiza los métodos configurados; el servidor compone el motor en auth-runtime y resuelve la sesión en cada límite protegido. Un primer acceso exitoso provisiona el workspace personal del miembro de forma idempotente — los hooks de ciclo de vida repetidos nunca deben crear un segundo registro de propiedad.
La seguridad de la cuenta vive bajo /settings/security: cambio de contraseña, sesiones activas y passkeys donde el build las habilita. Mantén la restauración de sesión, la revocación al cerrar sesión y la denegación entre workspaces como comportamiento aplicado en el servidor, no como estado de la interfaz.
Verificación y solución de problemas
Ejercita el acceso, códigos OTP inválidos y expirados, consumo de un solo uso, ceremonias de passkey en orígenes HTTPS, retornos de callback social, cierre de sesión y denegación anónima. Registra cada URI de redirección de proveedor antes de probar callbacks, y verifica que una sesión revocada no pueda seguir realizando trabajo protegido.