Cómo implementar autenticación multifactor y gestión de identidades en tu aplicación web

He montado el módulo de acceso de casi una docena de aplicaciones web a medida. Y el patrón se repite: el equipo pospone la decisión, llega la primera auditoría, y toca rehacer medio backend. No exagero.

El par usuario-contraseña, solo, lleva años sin frenar a nadie serio. Lo sabes tú y lo sabe el atacante que esta noche lanzará credential stuffing contra tu login. Aun así, sigo viendo aplicaciones B2B con formularios de acceso que aceptarían "admin/admin" si las dejaras.

Implementar autenticación multifactor gestión identidades aplicación web no es una funcionalidad. Es una decisión arquitectónica. Te afecta a seguridad, UX, cumplimiento y a la capacidad de añadir clientes enterprise sin reescribir el backend cada seis meses.

Lo que sigue es el manual operativo que uso cuando un CTO me llama y me dice "vamos a meter MFA". Sin teoría innecesaria. Decisiones, protocolos, qué funciona y qué te va a explotar en producción.

Por qué la contraseña sola ya no es suficiente

El informe anual de Verizon sobre brechas lleva años repitiendo lo mismo: más del 80 % de las brechas relacionadas con hacking involucran credenciales comprometidas o débiles. El credential stuffing es automatizado, barato y masivo. Un bot prueba millones de combinaciones por hora contra un login sin protección. Y la mayoría de logins web siguen sin protección decente.

MFA cambia el cálculo. Aunque el atacante tenga la contraseña, le falta el segundo factor: un dispositivo, una app, una huella. Microsoft publicó hace tiempo el dato que todos citamos: MFA bloquea el 99,9 % de los ataques automatizados contra cuentas. Es la mejora de seguridad con mejor ratio coste/beneficio que vas a meter en tu vida.

Aviso: MFA mal implementado es casi peor que no tenerlo. Flujos confusos disparan abandono. Sistemas de identidad mal diseñados generan silos de datos y bloquean cualquier integración futura. La diferencia entre éxito y desastre está en decisiones que se toman en una semana de diseño.

Factores de autenticación: qué opciones existen y cuál elegir

Tres categorías. Cada una basada en un principio distinto. Las repasamos rápido.

Algo que el usuario sabe

Contraseña, PIN, preguntas de seguridad. El factor más débil. Se roba, se adivina, se extrae con un email bien redactado.

Las preguntas de seguridad merecen un párrafo aparte: son un antipatrón. Punto. "Nombre de tu primera mascota" lo encuentra cualquiera en tu Instagram. Si las tienes en producción, quítalas.

Algo que el usuario tiene

Un smartphone con Google Authenticator, Authy o Microsoft Authenticator. Una llave física como YubiKey o Titan. Un token hardware. El propio número de teléfono para SMS.

Mi recomendación por defecto para el 90 % de los proyectos: TOTP (Time-Based One-Time Password) vía app de autenticación. Equilibrio óptimo entre seguridad y usabilidad. Funciona offline, no depende de operadora, no cuesta dinero por usuario.

¿SMS? Mejor que nada, pero con asterisco enorme. El SIM swapping permite a un atacante redirigir tus mensajes a otro dispositivo con una llamada al call center de la operadora. He visto pasarlo en clientes con cuentas comprometidas. Si tu app maneja datos financieros o sanitarios, el SMS no puede ser la única opción de segundo factor.

Algo que el usuario es

Biometría: huella, cara, iris, voz. Con los sensores actuales de móviles y portátiles, dejó de ser ciencia ficción.

En web se implementa con WebAuthn, estándar W3C. Trabaja con criptografía asimétrica: la clave privada nunca sale del dispositivo. Esto importa más de lo que parece. Significa que aunque te roben la base de datos, no hay credenciales biométricas que filtrar. No existen en tu servidor.

La combinación recomendada

Contraseña con políticas razonables, TOTP como segundo factor obligatorio, WebAuthn/passkeys como opción avanzada para los usuarios que quieran configurarla. Esta es la receta que recomiendo. Cubre la inmensa mayoría de casos sin convertir el login en una odisea.

OAuth2 y OpenID Connect: delegar la autenticación de forma segura

Empezamos por una distinción que casi todo el mundo confunde: OAuth2 no es autenticación. Es autorización. Sirve para que tu app acceda a recursos de un usuario en otro servicio (sus contactos de Google, sus repos de GitHub) sin conocer sus credenciales allí.

Autenticación delegada la hace OpenID Connect (OIDC), una capa montada encima de OAuth2. Cuando pones "Login con Google" en tu app, estás usando OIDC. El proveedor autentica al usuario y te devuelve un token ID con la info del usuario, un token de acceso para llamar APIs y, si quieres, un refresh token para renovar el acceso sin volver a pedir login.

Flujos de OAuth2 relevantes para aplicaciones web

Para aplicación web con backend, el único flujo que deberías considerar: Authorization Code Flow con PKCE (Proof Key for Code Exchange). PKCE añade protección contra interceptación del código de autorización. Crítico en dispositivos que no pueden guardar secretos de forma segura.

El flujo en cuatro pasos: tu app redirige al usuario al proveedor, el usuario se autentica allí, el proveedor te devuelve un código temporal, tu servidor intercambia ese código (con el PKCE verifier) por los tokens. Tu app jamás ve la contraseña del usuario.

El Implicit Flow devolvía tokens directamente en la URL. Está oficialmente desaconsejado desde OAuth 2.1 por vulnerabilidades estructurales. Si lo tienes en producción, migrar es prioridad uno. No es opinión, es la especificación.

Cuándo usar OAuth2/OIDC como proveedor externo vs. como arquitectura interna

Login social (Google, Microsoft, Apple, GitHub) reduce fricción de registro y traslada la responsabilidad de almacenar contraseñas al proveedor. En B2C es casi obligatorio. Mete al menos Google.

Importante: no sustituye tu sistema de identidad interno. Sigues necesitando gestionar perfiles, roles, permisos y sesiones en tu lado, independientemente de cómo entró el usuario.

SAML y SSO empresarial: integración con entornos corporativos

¿Tu app va a vendérsela a empresas? Te van a pedir SSO. Más pronto que tarde. Y ahí entra SAML (Security Assertion Markup Language) y Single Sign-On federado.

SAML es un estándar basado en XML para autenticación federada entre un proveedor de identidad (IdP: Active Directory Federation Services, Okta, Azure AD) y tu aplicación como proveedor de servicios (SP). El usuario se autentica una sola vez en su entorno corporativo y entra en tu app sin volver a teclear credenciales. Para IT corporativo es innegociable.

SAML vs. OIDC para SSO empresarial

SAML lleva más de veinte años en producción enterprise. Sigue siendo el estándar de facto en grandes empresas. OIDC es moderno, ligero (JSON en vez de XML) y mucho más cómodo de implementar.

La tendencia va hacia OIDC. Pero la realidad de los pliegos enterprise sigue siendo SAML. Mi recomendación práctica: soporta los dos. Si usas Keycloak, Auth0, Azure AD B2C o AWS Cognito, ya te dan ambos protocolos de fábrica. Te ahorras meses de implementación contra la especificación SAML, que tiene zonas oscuras.

Proveedores de identidad: build vs. buy

Una de las decisiones que más dinero te ahorra (o te tira) en los próximos tres años.

Construir internamente

Tiene sentido en tres casos: requisitos de identidad tan específicos que ningún proveedor cubre; restricciones regulatorias que impiden externalizar datos de identidad; o un equipo de seguridad maduro capaz de mantener el sistema actualizado frente a vulnerabilidades nuevas cada mes.

Frameworks como Spring Security (Java), Passport.js (Node.js) o Django Allauth (Python) te dan los ladrillos. Pero la responsabilidad de seguridad pasa entera a tu equipo. Incluyendo madrugadas cuando salga la próxima CVE crítica.

Usar un proveedor de identidad como servicio

Para el 80-90 % de proyectos, la decisión correcta. Sin discusión.

Mis opciones por escenario: Keycloak si quieres open source self-hosted con control total del despliegue. Auth0 (ahora parte de Okta) si priorizas experiencia de desarrollo pulida y SLA enterprise. AWS Cognito o Azure AD B2C si tu infra ya vive en esos clouds. Firebase Authentication si quieres salir a producción la semana que viene.

Si estás evaluando qué arquitectura de identidad necesita tu aplicación y cómo integrarla sin comprometer la seguridad ni la experiencia de usuario, en Tangram Consulting podemos ayudarte a diseñar e implementar la solución adecuada. Cuéntanos tu proyecto y analizamos tu caso sin compromiso.

Políticas de contraseñas que funcionan en la realidad

Las directrices NIST (SP 800-63B) tiraron a la basura la mitad de lo que llevábamos años haciendo. Muchas prácticas "obligatorias" son ahora contraproducentes. Si tu política de contraseñas la escribió alguien en 2012, toca actualizarla.

Lo que el NIST recomienda actualmente

Longitud mínima de 8 caracteres. Mínimo recomendado de 12 para cuentas privilegiadas. Permitir hasta 64 caracteres como mínimo, lo que abre la puerta a passphrases tipo "el perro de mi vecino ladra a las 7". Aceptar todos los caracteres Unicode, espacios incluidos. Verificar contra listas de contraseñas comprometidas como Have I Been Pwned. Bloquear de raíz contraseñas triviales tipo "password123" o "qwerty".

Lo que el NIST desaconseja

Forzar cambios periódicos cada 30, 60 o 90 días. Esta práctica empeora la seguridad. Los usuarios eligen contraseñas más débiles y predecibles porque saben que tendrán que cambiarlas. Acaban siendo "MiClave_Enero", "MiClave_Febrero". Solo cambia la contraseña cuando hay evidencia real de compromiso.

Exigir reglas de composición complejas (una mayúscula, un número, un símbolo). Reduce el espacio de contraseñas posibles y produce monstruos como "P@ssw0rd!" que cumplen todo y son triviales de romper.

Cumplimiento GDPR en la gestión de identidades

Si tu aplicación opera en UE o procesa datos de ciudadanos europeos, GDPR no es opcional. Y la gestión de identidades es uno de los puntos donde más sanciones se han impuesto.

Principios clave aplicados a la autenticación

Minimización de datos: recopila solo lo que necesitas. Si tu app no necesita el teléfono, no lo pidas en el registro "por si más adelante metemos MFA por SMS". Lo metes cuando lo necesites.

Consentimiento informado: el usuario tiene que saber qué datos guardas, por qué y durante cuánto tiempo. Un checkbox "acepto las condiciones" sin enlace a política de privacidad detallada no cumple. Sanciones de la AEPD por esto, las he visto.

Derecho de acceso y portabilidad: el usuario puede pedir un export de todos sus datos de identidad en formato legible por máquina. JSON sirve.

Derecho al olvido: el usuario puede pedir borrado completo. Tu sistema tiene que poder ejecutarlo de verdad, incluyendo logs, backups y datos en servicios de terceros. Esto último es lo que casi nadie tiene preparado.

Registro de actividad: log auditable de accesos, cambios de contraseña, activaciones de MFA, cualquier acción relevante sobre la identidad. Protegido contra manipulación. Útil también cuando hay un incidente y necesitas saber qué pasó.

Almacenamiento seguro de credenciales

Contraseñas hasheadas con algoritmo resistente a fuerza bruta. Bcrypt con factor de coste 12 o superior sigue siendo opción válida. Argon2id es la recomendación actual del Password Hashing Competition, con mejor resistencia contra GPUs y ASICs. Scrypt también vale.

Texto plano, MD5 o SHA-256 sin salt: jamás. Parece obvio. Sigue ocurriendo en producción con una frecuencia que da miedo.

Arquitectura recomendada para una aplicación a medida

Un diseño sólido contempla cuatro capas. Las uso como checklist en cada proyecto.

Capa de autenticación primaria

Gestiona login con credenciales propias y login social (OAuth2/OIDC). Rate limiting agresivo contra fuerza bruta: bloqueo temporal tras cinco intentos fallidos con incremento exponencial. Protección contra enumeración de usuarios: la respuesta a un login fallido no debe revelar si el email existe. Esto último se olvida casi siempre.

Capa de MFA

TOTP como segundo factor principal. WebAuthn/passkeys como opción avanzada. SMS solo como fallback y con aviso explícito al usuario sobre sus limitaciones. El usuario debe poder configurar varios factores y elegir uno principal. Códigos de recuperación de un solo uso para cuando alguien pierda el móvil. Lo van a perder. Te lo garantizo.

Capa de gestión de sesiones

JWT para comunicación entre servicios, pero almacena las sesiones en servidor (Redis, base de datos) para poder revocarlas al instante. Tokens de acceso de vida corta: 15-30 minutos. Refresh tokens de vida más larga (días o semanas), vinculados a un dispositivo y revocables. Sin esto, un token robado es válido hasta que expira y no puedes hacer nada.

Capa de autorización

Separada de la autenticación. RBAC (Role-Based Access Control) cubre el 90 % de los casos. Para permisos más granulares, ABAC (Attribute-Based Access Control) te deja definir políticas según atributos del usuario, del recurso y del contexto. Antes de saltar a ABAC, asegúrate de necesitarlo: añade complejidad significativa.

Errores frecuentes que debes evitar

Almacenar tokens en localStorage del navegador. Accesibles por cualquier XSS. Los tokens sensibles van en cookies httpOnly con flags Secure y SameSite. No negociable.

No implementar rotación de refresh tokens. Si un refresh token es robado y no hay rotación, el atacante tiene acceso indefinido sin que tú lo detectes. Rotación cada uso, con detección de reutilización para revocar la cadena entera si se detecta un token usado dos veces.

MFA solo en el login y no en operaciones sensibles. Cambio de contraseña, cambio de email, eliminación de cuenta: todas requieren re-autenticación. Si no, una sesión robada compromete la cuenta entera.

Confiar en el frontend para validaciones de seguridad. Toda validación de autenticación y autorización va en servidor. Siempre. El frontend mejora UX, nunca es control de seguridad. Cualquiera abre las DevTools y se salta lo que quieras.

Conclusión: la identidad como pieza fundacional

La autenticación e identidad no es un módulo plugable. Es base. Afecta a arquitectura, UX, cumplimiento y postura de seguridad. Cambiarla con la aplicación en producción cuesta diez veces más que diseñarla bien al principio.

Invertir tiempo en esta capa al inicio ahorra meses de refactor y evita la brecha que sale en titulares. Proveedor de identidad maduro, MFA bien implementado, OAuth2/OIDC/SAML como protocolos estándar, GDPR nativo. Esa es la base. Sobre ella se construye cualquier aplicación web a medida con la cabeza tranquila.