¿Qué es la autenticación? Inicios de sesión, sesiones y OAuth explicados

La autenticación es la forma en que una app confirma quién es un usuario: normalmente comprobando algo que la persona sabe (una contraseña), algo que tiene (un código enviado a su teléfono o email) o una identidad procedente de otro servicio de confianza (como «Iniciar sesión con Google»). Una vez autenticado el usuario, la app lo recuerda con una sesión o un token para que no tenga que iniciar sesión en cada página. Decidir qué puede hacer ese usuario conocido es un paso aparte llamado autorización.

Por qué importa cuando construyes con IA

Añadir un inicio de sesión es una de las peticiones más comunes a un constructor de apps con IA, y una de las más fáciles de hacer mal sin darse cuenta. Una página de login es sencilla de generar. Lo difícil es todo lo que la rodea:

¿Se guardan las contraseñas de forma segura?
¿Comprueba cada página privada y cada endpoint de la API quién está pidiendo los datos?
¿Puede un cliente con sesión iniciada ver los datos de otro cliente cambiando un número en la URL?
¿Qué pasa cuando alguien olvida su contraseña?

Una app puede parecer perfectamente segura y fallar en todas esas preguntas. Entender las piezas te permite hacer las preguntas correctas y probar lo correcto.

Una analogía cotidiana

Piensa en el registro de entrada de un hotel.

En recepción muestras tu documento de identidad. Eso es autenticación: demostrar quién eres. La recepcionista te da una tarjeta de acceso. Esa tarjeta es tu sesión: durante toda tu estancia no vuelves a enseñar el documento; solo pasas la tarjeta.

La tarjeta abre tu habitación, el gimnasio y el ascensor de tu planta, pero no las habitaciones de otros huéspedes ni la oficina del personal. Eso es autorización: a qué puede acceder tu identidad. Si pierdes la tarjeta, el hotel puede desactivarla en recepción (revocar la sesión). Al hacer el check-out deja de funcionar (cerrar sesión o caducidad).

«Iniciar sesión con Google» es como si un hotel aceptara una carta de un socio de confianza que dijera «esta es la persona», en lugar de comprobar tu documento él mismo.

Los principales métodos de inicio de sesión

Método	Cómo funciona	Ventajas	Inconvenientes
Email + contraseña	El usuario elige una contraseña; la app guarda un hash	Familiar, sin dependencias externas	Debes guardar los hashes con seguridad y gestionar los restablecimientos
Enlace mágico / código de un solo uso	La app envía por email un enlace o código que inicia la sesión	No hay contraseñas que filtrar u olvidar	Depende de la entrega del email; el acceso es más lento
Inicio de sesión social (OAuth / OpenID Connect)	El usuario entra con Google, Apple, GitHub, etc.	Rápido para el usuario; no guardas contraseñas	Configuración con cada proveedor; usuarios sin esas cuentas
Proveedor de autenticación alojado	Un servicio como Clerk, Auth0 o Supabase Auth gestiona el registro, el login y los restablecimientos	Menos trabajo de seguridad para ti	Coste mensual a gran escala; otra dependencia
Autenticación multifactor (MFA / 2FA)	Una segunda comprobación tras la primera, como un código de una app de autenticación	Mucho más difícil de vulnerar	Un poco más de fricción

Cómo deben guardarse las contraseñas

Una app segura nunca guarda tu contraseña real. Guarda un hash: el resultado de una función unidireccional que convierte la contraseña en una cadena fija. Cuando inicias sesión, la app calcula el hash de lo que escribiste y compara el resultado con el hash guardado.

Dos detalles hacen esto seguro:

Una sal: un valor aleatorio que se añade a cada contraseña antes de calcular el hash, de modo que dos personas con la misma contraseña obtienen hashes distintos y las tablas de búsqueda precalculadas no sirven de nada.
Un algoritmo lento pensado para contraseñas: como Argon2, bcrypt o scrypt. Los hashes de propósito general como MD5 o SHA-256 son demasiado rápidos por sí solos; un atacante puede probar miles de millones de adivinanzas.

Un hash no es lo mismo que un cifrado. Los datos cifrados pueden descifrarse con una clave; un hash de contraseña está diseñado para no poder revertirse.

Sesiones vs tokens

Después del login, la app necesita reconocerte en cada petición. Hay dos enfoques habituales.

	Sesión (cookie)	Token (p. ej. JWT)
Qué guarda el navegador	Un ID de sesión aleatorio en una cookie	Un token firmado con datos del usuario y una caducidad
Dónde vive el estado del login	En el servidor, en una base de datos o almacén	Dentro del propio token
Cerrar la sesión en todas partes	Fácil: borrar la sesión en el servidor	Más difícil: el token sigue válido hasta que caduque, salvo que mantengas una lista de bloqueo
Uso típico	Aplicaciones web tradicionales	APIs, apps móviles, servicios que se hablan entre sí

Para las cookies importan tres ajustes: HttpOnly (el JavaScript de la página no puede leer la cookie), Secure (se envía solo por HTTPS) y SameSite (limita el envío en peticiones desde otros sitios). Guardar tokens en el localStorage del navegador es habitual, pero los expone a cualquier script que se ejecute en la página.

OAuth e «Iniciar sesión con Google»

OAuth 2.0 es un estándar de autorización delegada: permite a una app obtener acceso limitado a tu cuenta en otro servicio —por ejemplo, leer tu Google Calendar— sin ver nunca tu contraseña de Google. Te envían a Google, apruebas permisos concretos (llamados scopes) y Google da a la app un token solo para esos permisos.

OAuth por sí solo se diseñó para conceder acceso, no para decir quién eres. OpenID Connect (OIDC) es una capa encima de OAuth 2.0 que añade identidad, y es lo que usan «Iniciar sesión con Google» o «Iniciar sesión con Apple». Para configurarlo registras tu app en el proveedor y obtienes un client ID y un client secret; el secreto se queda en tu servidor.

Ejemplo práctico: inicio de sesión para un portal de clientes

Supongamos que construyes un portal donde los clientes de una agencia de diseño ven sus proyectos y facturas.

Autenticación: los clientes entran con email y un enlace mágico, así que no hay contraseñas que gestionar. El personal de la agencia entra con cuentas de Google Workspace.
Roles: cada usuario tiene un rol: client o staff.
Reglas de autorización:

Acción	Cliente	Personal
Ver los proyectos de su propia empresa	Sí	Sí
Ver los proyectos de otras empresas	No	Sí
Subir un archivo a un proyecto	Solo a sus proyectos	Sí
Marcar una factura como pagada	No	Sí

Dónde se aplica: en el servidor, en cada petición. El servidor busca el usuario que ha iniciado sesión y solo devuelve los proyectos donde project.company_id coincide con la empresa del usuario. Ocultar el botón «Marcar como pagada» no basta: el endpoint en sí tiene que rechazar la petición.

Términos comunes explicados

Término	Significado
Autenticación (AuthN)	Confirmar quién es alguien.
Autorización (AuthZ)	Decidir qué puede hacer.
Sesión	La app recuerda que has iniciado sesión entre peticiones.
Cookie	Un pequeño dato que el navegador devuelve al sitio con cada petición.
JWT	JSON Web Token: un token firmado y compacto que contiene datos como el ID del usuario y la caducidad.
Rol / permiso	Etiquetas como `admin` o `member` que deciden el acceso.
MFA / 2FA	Exigir una segunda prueba, como un código de una app de autenticación.
SSO	Inicio de sesión único: un solo acceso (a menudo con una cuenta de empresa) para muchas apps.
401 vs 403	«¿Quién eres?» (no autenticado) frente a «No puedes hacer eso» (no autorizado).

Errores y conceptos erróneos habituales

Comprobar los permisos solo en la página. Si el navegador oculta un botón pero la API no comprueba nada, cualquiera puede llamar a la API directamente.
Confiar en los IDs de la URL. /invoices/1042 debe comprobar que la factura 1042 pertenece al usuario que ha iniciado sesión.
Inventar tu propia criptografía. Usa bibliotecas conocidas o proveedores; no dejes que la IA invente un esquema de hash.
Restablecimiento de contraseña débil. Los enlaces de restablecimiento deben ser de un solo uso, caducar rápido y no revelar si un email tiene cuenta.
Confundir tu login con el del constructor. Los usuarios de tu app son independientes de tu cuenta en la herramienta con la que la construyes.
Sin límite de intentos en el login. Sin él, los atacantes pueden probar contraseñas sin fin.

Qué pedir a tu constructor de apps con IA

«Añade registro e inicio de sesión usando [una biblioteca o proveedor conocido]. No escribas un hash de contraseñas personalizado.»
«Guarda las contraseñas con hash usando bcrypt o Argon2.»
«Usa cookies HttpOnly y Secure para la sesión.»
«Añade roles: admin y member. Enumera cada endpoint y qué roles pueden llamarlo.»
«Asegura en el servidor que los usuarios solo puedan leer y editar sus propios registros. Luego muéstrame cómo lo comprobaste.»
«Añade restablecimiento de contraseña con enlaces de un solo uso que caduquen en una hora.»
«Limita la frecuencia de los intentos de inicio de sesión.»

Después, pruébalo tú mismo: crea dos cuentas e intenta acceder a los datos de una mientras tienes la sesión iniciada con la otra. Nuestra guía para añadir login y la lista de comprobación de seguridad profundizan más.

Autenticación en Mythex

Mythex no ofrece un producto de autenticación integrado para los usuarios de tu app; tú eliges un enfoque —email y contraseña guardados en la base de datos de tu proyecto, o el SDK de un proveedor alojado— y pides al agente que lo añada. Las claves del proveedor van en los secretos del proyecto, no en el chat. Esto es independiente de cómo inicias sesión en Mythex en sí. La receta de la documentación sobre añadir login a tu app tiene un prompt inicial que puedes adaptar, y qué es una API explica dónde viven esas comprobaciones en el servidor.

Preguntas

¿Cuál es la diferencia entre autenticación y autorización?

La autenticación comprueba quién eres, por ejemplo verificando tu contraseña. La autorización decide qué puedes hacer una vez que se sabe quién eres, como si puedes ver la página de administración o editar la reserva de otra persona. Las apps necesitan ambas.

¿Qué es OAuth?

OAuth 2.0 es un estándar que permite a una app obtener acceso limitado a tu cuenta en otro servicio sin ver nunca tu contraseña. «Iniciar sesión con Google» usa OpenID Connect, una capa de identidad construida sobre OAuth 2.0, de modo que la app sabe quién eres gracias a Google.

¿Debe mi app guardar contraseñas?

Nunca en forma legible. Si usas inicio de sesión con email y contraseña, las contraseñas deben guardarse como hashes con sal, generados con un algoritmo lento diseñado para contraseñas, como Argon2 o bcrypt. Muchas apps evitan el problema usando un proveedor de autenticación alojado, inicio de sesión con redes sociales o enlaces mágicos por email.

¿Sesiones o tokens: cuál debe usar mi app?

Ambos funcionan. Una sesión guarda el estado del inicio de sesión en el servidor y da al navegador un ID aleatorio en una cookie, que es fácil de revocar. Un token, como un JWT, lleva la información firmada en sí mismo, lo que encaja bien con APIs y clientes móviles, pero es más difícil de cancelar antes de que caduque. Para una app web típica, las sesiones basadas en cookies son una opción sólida por defecto.