¿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 sabe (una contraseña), algo que tiene (un código enviado a su móvil o email) o una identidad de otro servicio de confianza (como «Iniciar sesión con Google»). Una vez autenticado el usuario, la app lo recuerda mediante una sesión o un token para que no tenga que iniciar sesión en cada página. Decidir qué puede hacer ese usuario ya identificado es un paso aparte, llamado autorización.
Por qué importa cuando creas con IA
Añadir un inicio de sesión es una de las peticiones más comunes que la gente hace a un creador 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?
- ¿Cada página privada y cada endpoint de la API comprueba realmente quién lo pide?
- ¿Puede un cliente con sesión iniciada ver los datos de otro cambiando un número en la URL?
- ¿Qué pasa cuando alguien olvida su contraseña?
Una app puede parecer perfectamente segura y fallar en todos esos puntos. Entender las piezas te permite hacer las preguntas adecuadas y probar lo que toca.
Una analogía cotidiana
Piensa en el registro de un hotel.
En recepción enseñas tu documento de identidad. Eso es autenticación: demostrar quién eres. Después, 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 acercas 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 que caduque).
«Iniciar sesión con Google» es como si un hotel aceptara una carta de un socio de confianza que dice «esta persona es quien dice ser», en lugar de comprobar el documento por sí mismo.
Los métodos de inicio de sesión principales
| Método | Cómo funciona | Ventajas | Inconvenientes |
|---|---|---|---|
| Email + contraseña | El usuario elige una contraseña; la app guarda un hash de ella | 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 un código que inicia sesión al usuario | No hay contraseñas que filtrar ni olvidar | Depende de la entrega del email; el acceso es más lento |
| Inicio con redes sociales (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 acceso y los restablecimientos | Menos trabajo de seguridad para ti | Coste mensual a gran escala; otra dependencia |
| Autenticación multifactor (MFA / 2FA) | Una comprobación adicional 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 de un solo sentido 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 que esto sea 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 diseñado 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 intentos.
El hash no es lo mismo que el cifrado. Los datos cifrados se pueden descifrar con una clave; un hash de contraseña está diseñado para no poder revertirse en absoluto.
Sesiones frente a tokens
Tras el inicio de sesión, la app necesita reconocerte en cada petición. Hay dos enfoques habituales.
| Sesión (cookie) | Token (p. ej., JWT) | |
|---|---|---|
| Lo que guarda el navegador | Un ID de sesión aleatorio en una cookie | Un token firmado con la información del usuario y una caducidad |
| Dónde vive el estado del inicio de sesión | En el servidor, en una base de datos o almacén | Dentro del propio token |
| Cerrar la sesión de alguien en todas partes | Fácil: borrar la sesión en el servidor | Más difícil: el token sigue válido hasta caducar, salvo que mantengas una lista de bloqueo |
| Uso típico | Aplicaciones web tradicionales | APIs, apps móviles, servicios que se comunican entre sí |
En las cookies importan tres ajustes: HttpOnly (el JavaScript de la página no puede leer la cookie), Secure (solo se envía por HTTPS) y SameSite (limita su 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 para la 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 o alcances) 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 sobre OAuth 2.0 que añade identidad, y es lo que usa «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.
Un ejemplo práctico: acceso a un portal de clientes
Imagina que creas un portal donde los clientes de una agencia de diseño ven sus proyectos y facturas.
- Autenticación: los clientes entran con su 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:
clientostaff. - 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 en 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 con la sesión iniciada y solo devuelve los proyectos cuyo
project.company_idcoincide 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 recordando 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 frente a 403 | «¿Quién eres?» (no autenticado) frente a «No puedes hacer eso» (no autorizado). |
Errores y malentendidos 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.
- Fiarse de los IDs de la URL.
/invoices/1042debe comprobar que la factura 1042 pertenece al usuario con la sesión iniciada. - Inventar tu propia criptografía. Usa librerías o proveedores conocidos; 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 inicio de sesión con el de tu creador. 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 creador de IA
- «Añade registro e inicio de sesión usando [una librería o proveedor conocido]. No escribas un sistema propio de hash de contraseñas.»
- «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. Lista cada endpoint y qué roles pueden llamarlo.»
- «Asegúrate en el servidor de que los usuarios solo puedan leer y editar sus propios registros. Después muéstrame cómo lo has comprobado.»
- «Añade restablecimiento de contraseña con enlaces de un solo uso que caduquen en una hora.»
- «Limita el número de intentos de inicio de sesión.»
Después, pruébalo tú: 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 explican más.
Autenticación en Mythex
Mythex no ofrece un producto de autenticación integrado para los usuarios de tu app; tú eliges el 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 el propio Mythex. La receta de la documentación sobre añadir login a tu app incluye 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 las dos.
¿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 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 texto legible. Si usas inicio de sesión con email y contraseña, las contraseñas deben guardarse como hashes con sal, creados 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: qué debe usar mi app?
Ambos funcionan. Una sesión guarda el estado de 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 dentro de sí mismo, lo cual encaja con las APIs y los 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.