Autenticación y autorización en aplicaciones web

La autenticación y la autorización son los pilares de la seguridad en cualquier aplicación web. Sin embargo, son también una fuente recurrente de vulnerabilidades graves: brechas de seguridad que exponen datos de millones de usuarios, cuentas comprometidas, escaladas de privilegios no autorizadas. La razón no es que sean conceptos difíciles en abstracto, sino que su implementación correcta requiere atención a muchos detalles que no siempre son evidentes, especialmente cuando se trabaja bajo presión de tiempo o sin experiencia previa en seguridad.

Es fundamental distinguir ambos conceptos desde el principio, porque se confunden con frecuencia. La autenticación responde a la pregunta ¿quién eres? y verifica la identidad del usuario. La autorización responde a ¿qué puedes hacer? y determina qué recursos y operaciones están permitidos para ese usuario autenticado. Puedes estar completamente autenticado (el sistema sabe quién eres) pero no autorizado para acceder a un recurso específico (no tienes permiso). Son capas independientes que deben implementarse por separado.

Esta guía cubre los mecanismos de autenticación más importantes (contraseñas, tokens JWT, OAuth 2.0, autenticación multifactor), los modelos de autorización principales (RBAC, ABAC, permisos basados en recursos), y las mejores prácticas de seguridad aplicables tanto si construyes tu propio sistema como si usas una solución de terceros. El enfoque es práctico y orientado a aplicaciones web profesionales.

Gestión de contraseñas: el fundamento que no puedes ignorar

A pesar de la proliferación de métodos de autenticación alternativos, las contraseñas siguen siendo el mecanismo más universal. Gestionarlas correctamente es fundamental. La regla más importante: nunca almacenes contraseñas en claro ni en formato reversible (cifradas). Siempre usa un algoritmo de hashing específico para contraseñas que sea lento por diseño y resista ataques de diccionario y rainbow tables. Los algoritmos recomendados en 2026 son Argon2id (el ganador de la Password Hashing Competition), bcrypt y scrypt. MD5, SHA-1 y SHA-256 no son adecuados para contraseñas.

El salt (un valor aleatorio único por usuario añadido antes de hashear) es imprescindible: garantiza que dos usuarios con la misma contraseña tengan hashes diferentes y hace inútiles los rainbow tables precomputados. Argon2id incorpora el salt automáticamente. Los parámetros de coste (iteraciones, memoria, paralelismo) deben configurarse para que el proceso tarde entre 250ms y 500ms en tu hardware objetivo: suficientemente lento para dificultar ataques de fuerza bruta a escala, suficientemente rápido para no degradar la experiencia del usuario en logins.

Políticas de contraseñas que realmente funcionan

Las guías NIST SP 800-63B (la referencia más actualizada en el tema) han cambiado la recomendación sobre políticas de contraseñas de forma significativa. En lugar de exigir rotación periódica obligatoria (que lleva a contraseñas débiles tipo Password1, Password2...), complejidad forzada con símbolos y números que resulta en patrones predecibles, y restricciones de longitud máxima absurda, las recomendaciones actuales son: permitir frases de contraseña largas (hasta 64 caracteres mínimo), verificar que la contraseña no aparece en listas de contraseñas filtradas (herramienta HaveIBeenPwned API), y exigir cambio solo cuando haya evidencia de compromiso.

Sesiones vs tokens: arquitecturas de estado

El mecanismo fundamental de persistencia de autenticación entre peticiones es, en las aplicaciones web tradicionales, la sesión: el servidor crea un identificador de sesión opaco, lo almacena en memoria o base de datos asociado a los datos del usuario, y lo envía al cliente en una cookie. En cada petición, el cliente envía la cookie, el servidor busca la sesión y recupera el contexto del usuario. Este enfoque stateful es simple de entender y fácil de invalidar: eliminar la sesión del almacén del servidor es suficiente para cerrar sesión de forma inmediata.

Los tokens JWT (JSON Web Tokens) son el enfoque stateless: el servidor genera un token firmado que contiene los datos del usuario, lo envía al cliente, y en cada petición el cliente incluye el token. El servidor verifica la firma criptográfica sin consultar ningún almacén externo. Esto elimina el requisito de un almacén de sesiones compartido y simplifica el escalado horizontal. La contrapartida es que revocar un token antes de su expiración requiere mantener una lista negra (lo que recupera parte del estado que querías eliminar) o aceptar una ventana de invalidez hasta la expiración.

JWT en profundidad: estructura, firma y uso correcto

Un JWT es una cadena codificada en Base64URL con tres partes separadas por puntos: header (algoritmo y tipo), payload (claims del usuario y metadatos) y signature (hash criptográfico del header y payload usando la clave secreta). La firma garantiza la integridad: cualquier modificación del token invalida la firma. Sin embargo, el contenido del token es legible por cualquiera que lo tenga (solo está codificado, no cifrado). Por tanto, nunca incluyas información sensible en el payload: contraseñas, tarjetas de crédito, datos médicos.

• Usar siempre algoritmos seguros: HS256 para secretos simétricos, RS256 o ES256 para pares de claves asimétricas. Nunca 'none'.
• Configurar tiempos de expiración cortos para access tokens: 15-60 minutos es el rango razonable.
• Implementar refresh tokens de larga duración con rotación y revocación en base de datos.
• Almacenar tokens en memoria o en cookies httpOnly; nunca en localStorage (vulnerable a XSS).
• Validar siempre el campo aud (audience) para evitar que tokens de un servicio sean válidos en otro.
• Implementar JTI (JWT ID) si necesitas revocación individual de tokens antes de su expiración.

OAuth 2.0 y OpenID Connect: delegación de identidad

OAuth 2.0 es un framework de autorización que permite a una aplicación (cliente) obtener acceso limitado a recursos en nombre de un usuario, sin que el usuario tenga que compartir sus credenciales con el cliente. Es el protocolo detrás del botón Iniciar sesión con Google o Continuar con GitHub que ves en miles de aplicaciones. OpenID Connect (OIDC) es una capa de identidad construida sobre OAuth 2.0 que añade la autenticación: además de autorizar al cliente a acceder a recursos, certifica quién es el usuario.

El flujo Authorization Code con PKCE es el recomendado para aplicaciones web y móviles en 2026. PKCE (Proof Key for Code Exchange) protege contra ataques de intercepción del código de autorización y hace innecesario el client_secret en clientes públicos (SPAs, apps móviles). El flujo funciona así: el cliente genera un code_verifier aleatorio y un code_challenge derivado de él, redirige al usuario al servidor de autorización con el challenge, el usuario se autentica y autoriza, el servidor redirige de vuelta al cliente con un código de autorización, y el cliente intercambia ese código por tokens presentando el code_verifier original para demostrar que es quien inició el flujo.

Implementar inicio de sesión social correctamente

El inicio de sesión con proveedores sociales (Google, Microsoft, Apple, GitHub) reduce la fricción del registro y delega la responsabilidad de la autenticación a proveedores con recursos de seguridad enormes. Sin embargo, su implementación tiene varios errores comunes que debes evitar. El primero es confiar ciegamente en el email del proveedor como identificador único: un usuario puede tener la misma dirección de correo en Google y GitHub, y si no gestionas esto correctamente, dos cuentas separadas de tu aplicación pueden quedar enlazadas o una puede sobreescribir a la otra. Usa el subject (sub) del ID token, que es un identificador único por proveedor, como clave primaria de vinculación.

Autenticación multifactor (MFA): capas adicionales de seguridad

La autenticación multifactor añade un segundo factor de verificación después de la contraseña, basado en algo que el usuario tiene (un dispositivo físico o móvil) o algo que el usuario es (biometría). Con MFA activado, el compromiso de la contraseña no es suficiente para acceder a la cuenta: el atacante también necesita el segundo factor. Según múltiples estudios de seguridad, el MFA previene más del 99% de los ataques de compromiso de cuentas automatizados.

• TOTP (Time-based One-Time Password): generadores de códigos de 6 dígitos que cambian cada 30 segundos. Compatible con apps como Google Authenticator, Authy y 1Password. Es el método MFA más equilibrado entre seguridad y facilidad de uso.
• Passkeys / WebAuthn: el estándar moderno basado en criptografía de clave pública. El dispositivo del usuario genera un par de claves; la clave privada nunca sale del dispositivo. Resistente a phishing por diseño. Soportado en todos los navegadores modernos.
• SMS/Email OTP: conveniente pero menos seguro (SIM swapping, interceptación). Aceptable para mitigación de riesgo pero no recomendable como único segundo factor para aplicaciones de alta seguridad.
• Hardware tokens (YubiKey): el nivel más alto de seguridad para cuentas con acceso a datos especialmente sensibles. Imprescindible para cuentas de administrador de sistemas.
• Notificaciones push: apps de autenticación como Duo que envían una notificación push para aprobar o denegar el acceso. Experiencia de usuario fluida con buen nivel de seguridad.

Modelos de autorización: RBAC, ABAC y permisos por recurso

La autorización determina qué puede hacer un usuario autenticado. El modelo más simple y más común es RBAC (Role-Based Access Control): se asignan roles a los usuarios (admin, editor, viewer, etc.) y los roles determinan qué operaciones están permitidas. RBAC es fácil de entender, fácil de administrar y suficiente para la mayoría de las aplicaciones. Su limitación es que no expresa bien condiciones contextuales: el usuario A puede editar el documento B porque es el autor, pero no puede editar el documento C aunque tenga el mismo rol que el autor de C.

ABAC (Attribute-Based Access Control) permite expresar políticas más complejas basadas en atributos del usuario, el recurso y el entorno: el usuario puede editar el documento si es el autor Y el documento está en estado borrador Y la hora actual está dentro del horario laboral. Esta flexibilidad viene con mayor complejidad de implementación y gestión. Para la mayoría de las aplicaciones SaaS, un modelo híbrido es el más práctico: RBAC para los permisos de alto nivel (planes de suscripción, roles dentro de una organización) y permisos por recurso (ownership) para el control de acceso a datos específicos.

Autorización en arquitecturas multitenancy

Las aplicaciones SaaS con múltiples tenants (organizaciones o empresas clientes) tienen un requisito adicional crítico: el aislamiento de datos entre tenants. El usuario A de la empresa X nunca debe poder ver, modificar ni inferir la existencia de datos de la empresa Y, aunque tenga el mismo rol dentro de su propia organización. Este aislamiento debe implementarse en el nivel de la capa de acceso a datos, no solo en la lógica de presentación. El patrón más robusto es incluir siempre el identificador del tenant en todas las consultas a la base de datos, idealmente automatizado a través del ORM o middleware de base de datos para que no dependa de que el desarrollador recuerde añadirlo manualmente.

Implementar autorización con bibliotecas especializadas

Para aplicaciones con requisitos de autorización no triviales, las librerías especializadas evitan reinventar la rueda. Casbin es una librería de control de acceso open source que soporta RBAC, ABAC y muchos otros modelos de control de acceso mediante un lenguaje de políticas declarativo. Funciona con múltiples lenguajes (Node.js, Python, Go, Java) y puede almacenar las políticas en base de datos o ficheros. Para arquitecturas orientadas a microservicios, Open Policy Agent (OPA) es el estándar de facto: un motor de políticas general que puede usarse para autorización, validación de configuración y control de admisión en Kubernetes.

Para aplicaciones Next.js o Node.js más pequeñas, implementar RBAC propio con una tabla de roles y permisos en PostgreSQL es completamente razonable y evita añadir dependencias complejas. El patrón básico: tabla users, tabla roles, tabla user_roles (many-to-many), tabla permissions y tabla role_permissions. Al autenticar, carga los permisos del usuario en el token o sesión y verifica en cada endpoint si el usuario tiene el permiso requerido. Esta simplicidad es una virtud: es fácil de entender, auditar y modificar.

Protección contra ataques comunes de autenticación

La implementación de autenticación expone a la aplicación a una serie de ataques específicos que debes mitigar activamente. El ataque de fuerza bruta intenta adivinar contraseñas probando miles de combinaciones: la contramedida es rate limiting en el endpoint de login por IP y por nombre de usuario, con bloqueo temporal después de N intentos fallidos. El credential stuffing reutiliza credenciales filtradas en otras brechas: además del rate limiting, detecta patrones de login anómalos (muchas cuentas distintas desde la misma IP en poco tiempo) y verifica contraseñas contra bases de datos de brechas conocidas.

El phishing es el vector de ataque más efectivo para robar credenciales, y la única defensa técnica sólida es WebAuthn/Passkeys, que vincula las credenciales al origen (dominio) de forma criptográfica y hace físicamente imposible que funcionen en un sitio de phishing aunque sea idéntico visualmente al legítimo. Para aplicaciones de alta seguridad, considera ofrecer Passkeys como opción de autenticación. La implementación es factible con librerías como SimpleWebAuthn y el soporte de navegadores es excelente en 2026.

Tokens CSRF y protección en formularios

Los ataques Cross-Site Request Forgery (CSRF) engañan al navegador del usuario para que realice peticiones autenticadas a tu aplicación desde un sitio externo. La contramedida clásica son los tokens CSRF: un token secreto generado por el servidor, incluido en los formularios y verificado en cada petición que modifica datos. Para APIs que usan JWT en Authorization header en lugar de cookies, CSRF no es relevante porque las peticiones cross-site no pueden incluir headers personalizados. Para aplicaciones con sesiones en cookies, la cabecera SameSite=Strict o SameSite=Lax proporciona protección CSRF sin necesidad de tokens en la mayoría de los casos modernos.

Gestión de sesiones y cierre de sesión seguro

El cierre de sesión debe invalidar completamente la sesión del lado del servidor, no solo eliminar la cookie del navegador. Si solo eliminas la cookie pero la sesión permanece válida en el servidor, un atacante que haya capturado el identificador de sesión puede seguir usándola. Para aplicaciones con JWT sin almacén de sesiones, implementa un mecanismo de revocación: una lista negra de tokens revocados en Redis con TTL igual a la expiración del token, o rotación de secrets de firma por usuario que invalide todos los tokens anteriores de ese usuario.

Las cookies de sesión deben configurarse siempre con los atributos de seguridad correctos: HttpOnly (no accesible desde JavaScript, protege contra XSS), Secure (solo se envía en HTTPS), SameSite=Strict o Lax (protección CSRF), y un Domain y Path adecuados para limitar el alcance. En aplicaciones con requisitos de seguridad altos, considera implementar timeouts de sesión por inactividad: si el usuario no hace ninguna petición en X minutos, la sesión expira automáticamente aunque la cookie siga presente en el navegador.

Soluciones de terceros: cuándo delegar la autenticación

Para muchos proyectos, especialmente startups y aplicaciones SaaS de tamaño medio, tiene mucho sentido delegar la autenticación a un proveedor especializado en lugar de construirla desde cero. Los beneficios son evidentes: las funcionalidades avanzadas (MFA, magic links, SSO empresarial con SAML, detección de dispositivos sospechosos) están implementadas y mantenidas por expertos; los incidents de seguridad son manejados por el proveedor; y el equipo puede centrarse en las funcionalidades de negocio diferenciadas.

Las opciones principales del mercado en 2026 son Clerk (excelente DX, UI preconstruida, sistema de organizaciones muy completo, ideal para SaaS B2B), Auth0 de Okta (el más veterano y completo, con soporte SSO empresarial y compliance maduro, más caro), Supabase Auth (integrada con la base de datos PostgreSQL de Supabase, open source y desplegable on-premise), Firebase Authentication (integrada con el ecosistema Google, simple para apps móviles y web ligeras) y Keycloak (open source, on-premise, ideal para empresas con requisitos de soberanía de datos o compliance estricto como el ENS).

Auditoría y logs de seguridad

Toda actividad relacionada con autenticación y autorización debe registrarse en logs inmutables y detallados. Los eventos que siempre deben registrarse incluyen: intentos de login exitosos y fallidos (con IP, user agent y timestamp), cambios de contraseña, habilitación y deshabilitación de MFA, cambios de permisos o roles, acceso a datos sensibles, y solicitudes que resultan en 401 o 403. Estos logs son imprescindibles tanto para detectar incidentes de seguridad en curso como para investigarlos después y para cumplir con requisitos regulatorios como el RGPD o el ENS.

Protege los logs contra modificación (write-once storage, firma criptográfica) y limita quién puede acceder a ellos. Los logs de autenticación contienen información sensible (IPs, patrones de comportamiento de usuarios) y deben tratarse con las mismas medidas de protección que cualquier otro dato personal. Define una política de retención alineada con tus obligaciones legales: en el ámbito europeo, el RGPD exige una base legal para retener logs que contengan datos personales y limita el período de retención al mínimo necesario para el fin declarado.

La seguridad de la autenticación no es un problema que se resuelve una vez: es un proceso continuo de revisión, actualización y adaptación a nuevas amenazas. El mayor error es creer que, una vez implementado, no necesita mantenimiento.