Cómo añadir inicio de sesión a tu app: contraseñas, enlaces mágicos, Google y roles

Para añadir inicio de sesión a una app, elige un método (correo y contraseña, enlaces mágicos —un enlace de acceso de un solo uso enviado por correo— o «Iniciar sesión con Google») e impleméntalo con una librería de autenticación probada o con un proveedor alojado, en lugar de hacerlo desde cero. Después decide qué puede hacer cada tipo de usuario (roles) y aplícalo en el servidor en cada página y en cada petición a la API. Las sesiones deben usar cookies seguras, caducar y terminar correctamente al cerrar sesión.

Esta guía repasa cada opción y los detalles que separan un inicio de sesión que funciona de uno que además es seguro. Para los conceptos que hay detrás, consulta qué es la autenticación.

Decide primero: ¿necesitas inicio de sesión?

El inicio de sesión añade fricción y responsabilidad. Lo necesitas cuando:

• Los usuarios tienen datos privados (sus reservas, documentos, facturas)
• Los usuarios pueden cambiar cosas que otros verán
• Cobras por el acceso
• Personas distintas necesitan permisos distintos (propietario, personal, cliente)

Quizá no lo necesites para una web de marketing, un directorio público o un formulario que solo te envía un correo. Una lista de espera no necesita cuentas; un campo de correo es suficiente.

Los cuatro métodos de inicio de sesión habituales

Muchas apps combinan dos: el inicio de sesión con Google más los enlaces mágicos por correo es una pareja popular que cubre a la mayoría de la gente sin guardar ninguna contraseña.

Correo y contraseña

Si ofreces contraseñas, estos puntos son imprescindibles:

• Aplica hash a las contraseñas con un algoritmo de hash lento pensado para ello. La guía de almacenamiento de contraseñas de OWASP recomienda Argon2id, con scrypt, bcrypt o PBKDF2 como alternativas. Nunca guardes contraseñas en texto plano ni con un hash rápido de propósito general.
• Los restablecimientos de contraseña usan un enlace aleatorio de un solo uso que caduca, enviado al correo verificado.
• No reveles qué correos tienen cuenta. «Si ese correo está registrado, hemos enviado un enlace para restablecer la contraseña» es mejor que «No se ha encontrado ninguna cuenta».
• Limita la frecuencia de los intentos de inicio de sesión y de restablecimiento para frenar la adivinación de contraseñas.
• Permite contraseñas largas y gestores de contraseñas; evita reglas que obliguen a combinaciones raras de caracteres.

Enlaces mágicos y códigos de un solo uso

Un enlace mágico es un enlace de acceso enviado al usuario por correo. Al pulsarlo, el usuario inicia sesión. Un código de un solo uso es la misma idea, pero escrito en lugar de pulsado.

• Los enlaces y los códigos caducan rápido y funcionan una sola vez.
• El enlace debe iniciar sesión en el dispositivo donde se pulsa, y el token no debe quedarse en los registros ni en las herramientas de analítica.
• Necesitas un envío de correo fiable; consulta cómo enviar correos desde tu app. Prueba con Gmail y Outlook, y revisa la carpeta de spam.

Iniciar sesión con Google (y otros proveedores OAuth)

«Iniciar sesión con Google» usa OAuth y OpenID Connect: Google confirma quién es el usuario y le dice a tu app su correo y su nombre. La configuración, a septiembre de 2026, se hace en la sección Google Auth Platform de la consola de Google Cloud:

1. Crea o selecciona un proyecto y rellena la página Branding: lo que ve el usuario en la pantalla de consentimiento (nombre de la app, correo de soporte, logotipo).
2. En la página Clients, crea un cliente de tipo «Aplicación web».
3. Añade los orígenes de JavaScript autorizados y los URI de redirección: las direcciones exactas donde se ejecuta tu app y a las que Google devuelve al usuario tras iniciar sesión.
4. Guarda el ID de cliente y el secreto de cliente en los secretos de tu app.

Cosas que suelen salir mal, según la documentación OAuth de Google:

• redirect_uri_mismatch: la dirección de redirección debe coincidir exactamente, incluidos http frente a https, las mayúsculas y cualquier barra final. Añade una para tu dirección de vista previa y otra para tu dominio en vivo.
• Se exige HTTPS: los URI de redirección deben usar HTTPS, salvo localhost durante el desarrollo.
• El parámetro state debe comprobarse al volver, para protegerse de la falsificación de peticiones entre sitios. Las buenas librerías lo hacen por ti.

Si solo pides información básica de inicio de sesión (nombre, correo, perfil), Google indica que la verificación de la app no es obligatoria. Pedir acceso al Gmail, Drive o Calendar de los usuarios es distinto y requiere verificación.

¿Construirlo tú o usar un proveedor?

Los dos primeros son razonables. Los proveedores alojados hacen más por ti, pero añaden una dependencia y a veces cobran por usuario activo; consulta los precios actuales en sus webs. Las librerías mantienen todo en tu base de datos, pero te dejan más por configurar correctamente. Elijas lo que elijas, pide a la IA que use esa solución en lugar de escribir a mano la lógica de contraseñas o sesiones.

Roles y permisos

El inicio de sesión te dice quién es alguien. Los permisos deciden qué puede hacer. Mantenlo simple al principio:

Reglas que importan más que los nombres de los roles:

• Comprueba en el servidor, siempre. Ocultar un botón en la página no impide que alguien llame directamente a la API.
• Filtra por propietario. Un miembro que pide «reserva 123» solo debe recibirla si es suya.
• Los usuarios no pueden ascenderse a sí mismos. Ignora los campos de rol enviados desde el navegador al actualizar el perfil.
• Por defecto, sin acceso. Las rutas nuevas deben requerir inicio de sesión salvo que decidas lo contrario.

Pruébalo con dos cuentas: inicia sesión con una, anota el ID de un registro, entra con la otra e intenta abrirlo. Nuestra lista de seguridad para apps creadas con IA tiene la prueba completa.

Seguridad de la sesión

Tras el inicio de sesión, la app recuerda al usuario con una sesión, normalmente una cookie. La guía de gestión de sesiones de OWASP recomienda:

• Cookies de sesión con Secure (solo HTTPS), HttpOnly (no legibles por scripts de la página) y SameSite
• Un nuevo ID de sesión al iniciar sesión, y otra vez cuando cambien los privilegios
• Un tiempo de inactividad y una duración máxima absoluta, aplicados en el servidor
• Un cierre de sesión que termine la sesión en el servidor, no solo borre la cookie
• Sesiones invalidadas cuando el usuario cambia la contraseña

Guardar los tokens de inicio de sesión en el almacenamiento local del navegador es habitual en los tutoriales, pero los expone a cualquier script que se ejecute en la página; las cookies seguras suelen ser la mejor opción por defecto en las apps web.

Un prompt que cubre lo esencial

Añade cuentas de usuario a esta app. Los usuarios pueden registrarse e iniciar sesión con correo y contraseña, o con Google. Usa [librería o proveedor] en lugar de código de autenticación propio. Aplica hash a las contraseñas con Argon2id o bcrypt. Añade el restablecimiento de contraseña por correo con un enlace de un solo uso que caduque en una hora. Mantén las sesiones en cookies seguras HttpOnly. Protege /dashboard y cada ruta /api para que solo los usuarios conectados puedan usarlas, y asegúrate de que los usuarios solo ven sus propios proyectos. Añade un rol «admin» que pueda ver a todos los usuarios; solo los administradores pueden llegar a /admin, comprobado en el servidor.

Después, prueba: regístrate, cierra sesión, inicia sesión, restablece la contraseña, intenta abrir una URL privada sin sesión y prueba con un registro de otro usuario.

Errores habituales en inicios de sesión creados con IA

• Protección solo en la página. La página redirige a los usuarios sin sesión, pero la API devuelve datos a cualquiera.
• Secretos en el navegador. Los secretos de cliente OAuth y las claves de administración del proveedor de autenticación van en el servidor.
• Mezclar las URL de vista previa y en vivo. El URI de redirección de Google o el enlace del correo de restablecimiento apunta a la vista previa, así que el inicio de sesión se rompe tras publicar.
• Sin verificación de correo. Cualquiera puede registrarse como anyone@empresa.com. Verifica el correo antes de conceder nada ligado a esa dirección.
• Probar solo el camino feliz. Prueba contraseñas incorrectas, enlaces caducados y una segunda cuenta.

Añadir inicio de sesión en Mythex

En Mythex, el inicio de sesión para los usuarios de tu app es algo que añades a tu app; es independiente de tu propia cuenta de Mythex. Mythex no ofrece un producto de autenticación integrado, así que llevas tu propia librería o proveedor de autenticación y sus claves:

1. Elige un enfoque: por ejemplo, correo y contraseña guardados en tu propia base de datos, o el SDK de un proveedor alojado.
2. Si guardas los usuarios tú mismo, la app necesita una base de datos; pídela en el chat o usa /database.
3. Guarda las claves del proveedor en los secretos del proyecto (/secrets o los ajustes del proyecto).
4. Usa un prompt como el de arriba y prueba en la vista previa. Para el inicio de sesión con Google, añade URI de redirección para tu vista previa y para tu dirección publicada.

Consulta Add login to your app en la documentación. Si estás construyendo un producto de pago, cómo crear un MVP de SaaS explica las cuentas y la facturación juntas.

Preguntas