Métodos de autenticación que funcionan en 2026

8 min de lectura

Lo que realmente funciona para iniciar sesión

El problema de las contraseñas que creemos resuelto

La mayoría de los sitios web siguen usando inicio de sesión con correo y contraseña. La mayoría de los usuarios reutilizan la misma contraseña en docenas de servicios. La mayoría de las brechas explotan exactamente eso. Lo sabemos desde hace veinte años y hemos respondido con reglas de complejidad que castigan a los usuarios legítimos mientras apenas incomodan a los atacantes que compran volcados de credenciales al por mayor.

La buena noticia: las alternativas viables ya no son teóricas. Se distribuyen en cada navegador y sistema operativo importante. La mala noticia: la mayoría de los equipos de desarrollo no se han puesto al día.

Esto es lo que hay disponible y lo que vale la pena.

Passkeys y WebAuthn

Las passkeys son la mejora más significativa en la autenticación web desde que existe la autenticación web. Construidas sobre el estándar WebAuthn (ahora en Level 3), reemplazan las contraseñas por criptografía de clave pública. La clave privada nunca sale del dispositivo del usuario. El servidor solo almacena una clave pública. Nada que robar de la base de datos.

Apple, Google y Microsoft sincronizan passkeys a través de sus respectivos ecosistemas. Un usuario que crea una passkey en su iPhone puede usarla en su Mac, su iPad y, mediante autenticación entre dispositivos, incluso en una máquina con Windows. Android lo maneja a través de Google Password Manager. Windows usa Windows Hello.

Para desarrolladores, la API de WebAuthn es directa. Se llama a navigator.credentials.create() para el registro y navigator.credentials.get() para el inicio de sesión. Bibliotecas como SimpleWebAuthn (JavaScript), py_webauthn (Python) y webauthn-rs (Rust) manejan la verificación criptográfica en el servidor. El proceso son unas pocas llamadas API, no una tesis doctoral.

El principal reto: usuarios sin dispositivos compatibles con passkeys o que cambian entre ecosistemas. Probablemente se necesite una opción alternativa durante un tiempo.

Por dónde empezar: La documentación de passkeys.dev es excelente. Las guías para desarrolladores de Apple y Google recorren la implementación paso a paso. Como biblioteca del lado del servidor, SimpleWebAuthn tiene la mejor documentación en el ecosistema JavaScript.

OAuth 2.0 y OpenID Connect

OAuth 2.0 con OpenID Connect (OIDC) sigue siendo el estándar para autenticación delegada. “Iniciar sesión con Google”, “Iniciar sesión con GitHub” y flujos similares usan esto. La aplicación nunca ve la contraseña del usuario. El proveedor de identidad maneja la autenticación y entrega un token.

OIDC añade una capa de identidad sobre el framework de autorización de OAuth 2.0. Se obtiene un token de identidad (un JWT firmado) que indica quién es el usuario, más un token de acceso para llamadas API. El flujo Authorization Code con PKCE es el enfoque recomendado para aplicaciones web. El flujo implícito está obsoleto. No usarlo.

Para la mayoría de las aplicaciones web, el inicio de sesión social a través de OIDC cubre una porción significativa de usuarios. Solo Google gestiona la autenticación de miles de millones. GitHub funciona bien para productos orientados a desarrolladores. Apple Sign In es obligatorio para apps de iOS que ofrecen inicio de sesión con terceros.

La desventaja: se depende de proveedores externos. Si el servicio de autenticación de Google tiene una caída, los usuarios no pueden iniciar sesión. También se heredan sus políticas de privacidad y cualquier cambio en sus requisitos de autenticación.

Por dónde empezar: Auth0, Clerk y Supabase Auth ofrecen flujos OIDC gestionados que evitan implementar el protocolo uno mismo. Para ejecutarlo internamente, Keycloak y Authentik son opciones sólidas de código abierto.

Magic Links

Los magic links envían una URL de inicio de sesión de un solo uso al correo del usuario. Clic en el enlace, y dentro. Sin contraseña que recordar, sin contraseña que robar. Slack popularizó este patrón hace años.

La implementación es sencilla: generar un token criptográficamente aleatorio, almacenarlo con un tiempo de expiración (10 a 15 minutos), enviarlo como enlace por correo, y cuando el usuario hace clic, validar el token y crear una sesión. Invalidar el token inmediatamente después del uso.

La experiencia es buena para aplicaciones que se visitan ocasionalmente. Para aplicaciones de uso diario, el constante ir y venir al correo se convierte en fricción. Combinar magic links con sesiones de larga duración y cookies de “recordar este dispositivo” para reducir esa molestia.

La seguridad depende enteramente de la seguridad del correo electrónico. Si alguien puede acceder a la bandeja de entrada del usuario, puede iniciar sesión. Es un riesgo real, pero no peor que los flujos de restablecimiento de contraseña, que todo sistema basado en contraseñas ya tiene.

Autenticación multifactor

La autenticación multifactor (MFA) debería ser la norma, no la excepción. Se combina algo que el usuario sabe (contraseña o PIN) con algo que tiene (dispositivo) o algo que es (biometría).

Opciones, ordenadas aproximadamente por seguridad:

1. Llaves de seguridad de hardware (YubiKey, Titan) con FIDO2. Resistentes al phishing. Nada que interceptar.
2. Passkeys con verificación biométrica. El dispositivo es el segundo factor. Touch ID, Face ID, Windows Hello.
3. Apps TOTP (Google Authenticator, Authy, 1Password). Códigos de seis dígitos que rotan cada 30 segundos. Bien entendidos, ampliamente soportados.
4. Notificaciones push a través de apps de autenticación. Cómodas pero vulnerables a ataques de fatiga MFA (bombardear al usuario con solicitudes hasta que apruebe una).
5. Códigos SMS. Mejor que nada. Vulnerables a SIM swapping y ataques SS7. Usar como último recurso, no como primera opción.

Si la aplicación maneja dinero, datos de salud o cualquier cosa cuya pérdida disgustaría a los usuarios: exigir MFA. No solo ofrecerlo. Exigirlo.

Por dónde empezar: El estándar TOTP se define en RFC 6238. Existen bibliotecas para cada lenguaje. Para soporte de llaves de hardware, la misma infraestructura WebAuthn que impulsa las passkeys gestiona las llaves de seguridad FIDO2.

Gestión de sesiones: JWTs o sesiones del lado del servidor

Después de la autenticación, hay que mantener al usuario conectado. Dos enfoques:

Sesiones del lado del servidor: almacenan datos de sesión en el servidor (en memoria, Redis o una base de datos). El cliente recibe un identificador de sesión opaco en una cookie. Simple, revocable, probado en batalla. Cuando un usuario cierra sesión o hay que invalidar una sesión, se borra del almacén. Listo.

JWTs: codifican datos de sesión en un token firmado almacenado en el lado del cliente. Sin estado en el servidor. El token es autónomo. Suena elegante hasta que hay que revocar uno. Los JWTs son válidos hasta que expiran. Si la cuenta de un usuario está comprometida y hay que terminar su sesión inmediatamente, se acaba construyendo una lista de bloqueo de tokens, que no es más que un almacén de sesiones del lado del servidor con pasos extra.

Para la mayoría de las aplicaciones web: usar sesiones del lado del servidor. Son más simples, revocables y no requieren resolver problemas que solo existen porque se eligieron JWTs. Reservar los JWTs para comunicación API-a-API donde la ausencia de estado realmente importa.

Autenticación de APIs

Para comunicación máquina a máquina y acceso a APIs:

• Claves API para casos simples. Fáciles de implementar, fáciles de rotar. No enviarlas en parámetros de query. Usar el header Authorization.
• OAuth 2.0 Client Credentials para llamadas servicio a servicio donde se necesitan permisos con alcance definido.
• TLS mutuo (mTLS) para entornos de alta seguridad donde tanto cliente como servidor presentan certificados.

Las claves API son suficientes para la mayoría de servicios internos y APIs para desarrolladores. Solo hay que asegurar que tengan alcance definido, sean rotables y nunca se incluyan en el control de versiones. (Revisar el historial de git ahora mismo. Probablemente haya alguna.)

Lo que hay que dejar de hacer

Algunas prácticas deben desaparecer:

• Inicio de sesión solo con contraseña, sin MFA. Estamos en 2026. Basta.
• SMS como único segundo factor. El SIM swapping es trivial para atacantes motivados.
• Inventar criptografía propia. Usar bibliotecas establecidas. Cada vez que alguien construye un formato de token personalizado, un investigador de seguridad encuentra una forma de evadirlo en pocas semanas.
• Almacenar contraseñas en algo que no sea bcrypt, scrypt o Argon2. Si la base de datos tiene contraseñas con hash SHA-256, hay un problema.
• Preguntas de seguridad. El apellido de soltera de la madre está en Facebook. El nombre de la primera mascota está en Instagram. Eso no es seguridad. Es teatro.

Elegir el stack de autenticación

Para una nueva aplicación web en 2026, un punto de partida razonable:

1. Principal: Passkeys para usuarios con dispositivos modernos.
2. Alternativa: Magic links para usuarios sin soporte de passkeys.
3. Corporativo: Integración OIDC con proveedores de identidad empresariales (Azure AD, Okta).
4. MFA: Obligatorio, usando TOTP o llaves de hardware.
5. Sesiones: Del lado del servidor, almacenadas en Redis, con cookies HTTP-only secure.

Esta combinación cubre la mayoría de usuarios, resiste el phishing y no requiere construir un sistema de gestión de contraseñas propio.

La autenticación no es la parte más emocionante de construir un producto. Pero es la parte que sale en los titulares cuando falla. Invertir el tiempo para hacerlo bien. Las herramientas son mejores que nunca.