La autenticación sin contraseña verifica la identidad del usuario sin necesidad de introducir una contraseña. En lugar de secretos compartidos, se basa en lo que el usuario tiene (un dispositivo o un código de un solo uso) o en su identidad (huellas dactilares, reconocimiento facial).

Para los desarrolladores, la autenticación sin contraseña simplifica los flujos de inicio de sesión y ayuda a reducir la superficie de ataque que crean el almacenamiento y la gestión de contraseñas. Elimina la carga operativa que suponen los restablecimientos de contraseñas, los bloqueos de cuentas y la supervisión de intrusiones. Los métodos sin contraseña también mejoran la experiencia del usuario, pues reducen la fatiga de contraseña y las solicitudes de asistencia.

Según el informe Verizon Data Breach Investigations Report (DBIR) de 2025, el uso indebido de credenciales sigue siendo el principal vector de acceso inicial en las filtraciones, con el 22 % de los casos.

Las implementaciones modernas emplean estándares como FIDO2, WebAuthn y criptografía basada en dispositivos para ofrecer una autenticación segura y fácil de usar que elimina la necesidad de contraseñas.

Las contraseñas crean vulnerabilidades de seguridad y una carga operativa que afecta a los usuarios y a los equipos de desarrollo. Requieren almacenamiento seguro mediante algoritmos de hash adaptativos (como Argon2, bcrypt o PBKDF2), supervisión de filtraciones y políticas de bloqueo de cuentas. Las solicitudes de asistencia relacionadas con contraseñas suelen aumentar el volumen de trabajo de la mesa de ayuda.

Los usuarios suelen reutilizar sus contraseñas en varios sitios web. Esto permite que se ejecuten ataques de relleno de credenciales, en los que las credenciales filtradas tras un ataque se reutilizan para obtener acceso a otros servicios.

La autenticación sin contraseña aborda tres problemas fundamentales:

• Seguridad. Las contraseñas son vulnerables al phishing, el relleno de credenciales, los ataques de repetición y las filtraciones de bases de datos. Los atacantes pueden robar contraseñas mediante ingeniería social, malware o el acceso no autorizado a la base de datos. Los métodos sin contraseña, particularmente los que emplean criptografía asimétrica como WebAuthn, ayudan a erradicar estos vectores de ataque relacionados con secretos compartidos, ya que eliminan la necesidad de compartirlos. Con WebAuthn, las claves privadas nunca se transmiten desde el dispositivo, lo que hace que el robo remoto de credenciales sea prácticamente imposible.
• Experiencia del usuario. Los restablecimientos de contraseña provocan el abandono del proceso durante las fases críticas del recorrido del usuario y pueden generar un gran volumen de solicitudes de asistencia. Los usuarios suelen olvidar sus contraseñas, lo que da como resultado errores al intentar iniciar sesión y un aumento en las solicitudes de asistencia. La autenticación sin contraseña permite a los usuarios autenticarse con funciones del dispositivo que ya conocen (como el reconocimiento facial o la huella dactilar) o métodos de verificación sencillos (como códigos de un solo uso), lo que reduce las fricciones y aumenta los porcentajes de conversión.
• Sobrecarga para los desarrolladores. La gestión del almacenamiento de contraseñas requiere implementar hash seguros con factores de trabajo adecuados, generar salts y supervisar posibles filtraciones. Los flujos de restablecimiento de contraseñas necesitan infraestructura de correo electrónico, gestión de tokens y control de caducidad. Las políticas de bloqueo de cuentas requieren el seguimiento de los intentos fallidos y la implementación de mecanismos de desbloqueo. La autenticación sin contraseña elimina o reduce significativamente estos requisitos de implementación, lo que permite a los desarrolladores ocuparse de las funciones principales de la aplicación.

La autenticación sin contraseña sigue siempre el mismo patrón:

1. Verificación de identidad. El usuario demuestra que controla un factor de posesión (por ejemplo, un dispositivo, una llave de hardware, una dirección de correo electrónico o un teléfono) o un factor de inherencia (por ejemplo, un dato biométrico).
2. Validación del lado del servidor. El servidor de autenticación valida esta prueba mediante firmas criptográficas (métodos asimétricos) o códigos con límite de tiempo (métodos OTP).
3. Emisión de tokens. Una vez que el usuario completa la autenticación, el cliente intercambia el código de autorización en el extremo del token mediante PKCE. El extremo del token devuelve un token de ID (que contiene información de identidad) y un token de acceso (para la autorización de la API). Los tokens nunca se devuelven por el canal frontal.
4. Establecimiento de la sesión. La aplicación establece una sesión con cookies seguras HttpOnly o almacenamiento de sesión del lado del servidor.

Los métodos asimétricos (WebAuthn, claves de acceso) protegen las credenciales contra la exfiltración remota. Los códigos OTP enviados por correo electrónico, los códigos SMS y los códigos TOTP exponen información confidencial que los atacantes pueden interceptar o aprovechar.

WebAuthn (FIDO2)

WebAuthn permite que los navegadores y dispositivos creen pares de claves asimétricas. La clave privada permanece en el dispositivo y nunca se transmite. El servidor almacena únicamente la clave pública. Durante la autenticación, el servidor emite un desafío y el dispositivo lo firma con la clave privada, lo que demuestra la posesión sin exponer la clave.

WebAuthn ofrece sólidas garantías criptográficas con integración nativa en la plataforma en muchos navegadores y sistemas operativos modernos. Los usuarios se autentican mediante sensores biométricos integrados o llaves de seguridad de hardware.

Claves de acceso

Las claves de acceso son credenciales WebAuthn que se sincronizan en todo el ecosistema de dispositivos de un usuario mediante los administradores de credenciales que ofrece la plataforma. Los usuarios se autentican mediante datos biométricos o un PIN del dispositivo, y pueden autenticarse en diferentes dispositivos escaneando un código QR.

Las claves de acceso mantienen la seguridad criptográfica de WebAuthn y, al mismo tiempo, aumentan la facilidad de uso gracias a la sincronización. Si bien el mecanismo de sincronización amplía la superficie de ataque si la cuenta del usuario se ve en riesgo, las protecciones criptográficas subyacentes permanecen intactas.

Contraseñas de un solo uso (OTP)

• Códigos de verificación por correo electrónico. Los usuarios reciben códigos de verificación por correo electrónico. La seguridad depende de la seguridad de la cuenta de correo electrónico del usuario. Ideal para aplicaciones orientadas a consumidores que priorizan la conversión de registros o la recuperación de cuentas.
• OTP por SMS. Vulnerables a ataques de duplicado de tarjeta SIM e interceptación de mensajes. Evite usar OTP por SMS en entornos de alta seguridad, a menos que no haya otra alternativa.
• Contraseñas de un solo uso basadas en el tiempo (TOTP). Las aplicaciones de autenticación generan códigos a nivel local, lo que elimina el riesgo de interceptación. Sin embargo, las TOTP siguen siendo vulnerables a ataques de phishing o de retransmisión en tiempo real (man-in-the-middle). Un atacante que convenza a un usuario de introducir su código TOTP actual en un sitio web malicioso puede reenviarlo inmediatamente al servicio legítimo durante el período de validez de aproximadamente 30 segundos. Las TOTP cumplen con los requisitos de MFA en algunos entornos normativos, pero no son resistentes al phishing.

Enlaces mágicos

Los usuarios reciben enlaces de autenticación de un solo uso por correo electrónico. Al hacer clic en el enlace, se completa la autenticación. Los enlaces mágicos simplifican la experiencia del usuario, pero dependen de la seguridad del correo electrónico y ofrecen una protección limitada contra el phishing. Son ideales para aplicaciones orientadas a consumidores con límites de tiempo estrictos (a menudo, de 5 a 15 minutos) y restricciones de un solo uso.

Notificaciones push

Las aplicaciones de autenticación envían solicitudes de aprobación a los dispositivos registrados. Los usuarios seleccionan la acción (“aprobar” o “rechazar”) en lugar de ingresar un código. La aprobación mediante notificaciones push ofrece una mejor experiencia de usuario que las TOTP, pero sigue siendo vulnerable a los ataques por fatiga de autenticación multifactor (MFA), en los que los atacantes envían solicitudes push masivas con la esperanza de que los usuarios las aprueben por error. Las notificaciones push son más adecuadas para entornos empresariales que exigen capacitación de usuarios y detección de anomalías.

La autenticación sin contraseña abarca múltiples métodos, las claves de acceso representan una implementación específica y la MFA describe un requisito de seguridad. En la siguiente tabla, se explica cómo se interrelacionan estos conceptos:

Concepto	Definición	Ejemplo
Autenticación sin contraseña	Cualquier método de autenticación sin contraseña	WebAuthn, claves de acceso, enlaces mágicos, TOTP, OTP por correo electrónico
Claves de acceso	Credenciales WebAuthn sincronizadas con verificación de usuario integrada	Autenticación con reconocimiento facial o huella dactilar
MFA	Dos o más factores independientes de diferentes categorías	Contraseña + TOTP, o solamente clave de acceso (posesión + biometría)

Las claves de acceso, como autenticador único y resistente al phishing, suelen cumplir o superar los requisitos de seguridad tradicionales de la MFA al combinar un factor de posesión (el dispositivo con la clave privada) y un factor de verificación del usuario (biometría o PIN) en un solo paso.

WebAuthn representa la implementación moderna más segura sin usar una contraseña, y la criptografía asimétrica ayuda a eliminar el robo de credenciales.

• Registro. La aplicación (que actúa como entidad de confianza de WebAuthn) solicita la creación de credenciales al autenticador del usuario. El autenticador genera un par de claves asimétricas específico para el dominio de la aplicación. El servidor almacena la clave pública, el ID de la credencial y los metadatos (p. ej., la certificación del autenticador, cuando lo exige la normativa). La clave privada nunca sale del dispositivo de autenticación; los usuarios no pueden exportar manualmente las claves privadas de los autenticadores de la plataforma. El aislamiento en el dispositivo proporciona la garantía de seguridad fundamental de WebAuthn.
• Autenticación. El servidor genera un desafío criptográfico único (normalmente, un valor aleatorio). El autenticador firma este desafío con la clave privada almacenada de forma segura en el dispositivo. El servidor valida la firma con la clave pública almacenada para esa credencial. El autenticador vincula criptográficamente la firma al dominio de la aplicación, lo que invalida la respuesta firmada en cualquier otro sitio. La vinculación al dominio previene los ataques de phishing, ya que, incluso si un usuario intenta autenticarse en un sitio malicioso, la respuesta firmada solo funciona para el dominio legítimo.
• Emisión de tokens. Después de una autenticación exitosa, el proveedor de identidad emite tokens (con protocolos seguros, como OpenID Connect y OAuth 2.0 con PKCE), que normalmente incluyen un token de ID para la información de identidad y un token de acceso para la autorización de la API.
• Establecimiento de sesión. La aplicación establece una sesión mediante cookies seguras HttpOnly con los indicadores “Secure” y “SameSite”, o mediante el almacenamiento de la sesión en el servidor. Nunca almacene tokens en localStorage ni en sessionStorage debido a las vulnerabilidades de secuencias de comandos entre sitios (XSS). Genere un nuevo identificador de sesión inmediatamente después de una autenticación exitosa para prevenir ataques de fijación de sesión.

• Resistencia al phishing. Elija WebAuthn o las claves de acceso en vez de las OTP o los enlaces mágicos. La criptografía asimétrica proporciona una resistencia inherente al phishing mediante desafíos vinculados al dominio.
• Almacenamiento de tokens. Use cookies HttpOnly con los indicadores Secure y SameSite, o almacenamiento de sesión en el backend. Evite localStorage y sessionStorage.
• PKCE. Use el flujo de código de autorización con PKCE para todos los tipos de clientes a fin de evitar la interceptación de códigos de autorización.
• Limitación de frecuencia: aplique la limitación de frecuencia a los extremos de las OTP. Los códigos de seis dígitos solo tienen un millón de combinaciones. Implemente límites por IP, usuario, extremo y plazo.
• Seguridad de la sesión: regenere los identificadores de sesión tras una autenticación exitosa para prevenir ataques de fijación de sesión. Implemente un tiempo de espera por inactividad (30 minutos) y una caducidad absoluta (de 8 a 24 horas).
• Recuperación de dispositivos perdidos: proporcione métodos de reinscripción seguros. Para las claves de acceso, los usuarios se autentican desde dispositivos sincronizados. Para las credenciales no sincronizadas, use la recuperación por correo electrónico verificado, la recuperación administrativa o la aprobación de dispositivos de confianza.
• Confirmación: use la confirmación del autenticador solo cuando el cumplimiento normativo requiera la verificación con hardware (por ejemplo, la certificación FIPS). La confirmación agrega complejidad y puede reducir la adopción.

Método	Uso ideal	Concesiones de seguridad
Claves de acceso	Aplicaciones para consumidores, navegadores modernos, autenticación frecuente	El mecanismo de sincronización depende de la seguridad de la cuenta en la nube
WebAuthn (sin sincronización)	Aplicaciones empresariales, dispositivos gestionados, requisitos de seguridad más exigentes	Los usuarios no pueden autenticarse fácilmente desde dispositivos nuevos
OTP por correo electrónico	Registro y recuperación de cuentas con mínima fricción	La seguridad depende de la cuenta de correo electrónico
TOTP	Seguridad moderada, fricción de configuración aceptable	Vulnerable al phishing en tiempo real
OTP por SMS	Solo como respaldo	Ataques de duplicado de SIM, interceptación de mensajes

• Creer que las TOTP son resistentes al phishing: los atacantes pueden obtener TOTP mediante phishing en tiempo real a través de ataques de proxy.
• Limitación de frecuencia inadecuada: los atacantes pueden descifrar códigos de seis dígitos mediante fuerza bruta sin límites de frecuencia adecuados en varias dimensiones.
• Almacenamiento incorrecto de credenciales: almacene solo claves públicas. Nunca realice copias de seguridad ni sincronice manualmente las claves privadas.
• Flujos de recuperación débiles: implemente la reinscripción segura antes de que sea necesario. Realice pruebas con el personal de soporte.
• Seguridad de sesión insuficiente: regenere los ID de sesión después de la autenticación. Un atacante que fijó un ID de sesión puede secuestrarlo si no hay regeneración.

La autenticación sin contraseña, ¿es más segura que las contraseñas?

Cuando se implementa correctamente, lo es. Los métodos sin contraseña reducen la exposición al phishing, el robo de credenciales y las filtraciones de bases de datos. Sin embargo, la seguridad depende de la implementación. Las contraseñas de un solo uso enviadas por correo electrónico no son más seguras por naturaleza que las contraseñas fuertes, siempre y cuando se implementen las políticas adecuadas.

¿Son las claves de acceso un tipo de autenticación sin contraseña?

Sí. Las claves de acceso son credenciales de WebAuthn que se sincronizan entre dispositivos mediante mecanismos de sincronización seguros proporcionados por la plataforma, que combinan la seguridad de WebAuthn con una mayor facilidad de uso.

¿Puede la autenticación sin contraseña cumplir con los requisitos de la MFA?

Sí, cuando se trata de dos factores independientes. Las claves de acceso cumplen con la MFA al combinar la posesión del dispositivo con la verificación biométrica o el PIN del dispositivo. La TOTP puede usarse como segundo factor en la MFA, pero no es un método de MFA por sí solo.

¿Qué pasa si un usuario pierde su dispositivo?

Se deben ofrecer métodos seguros para la reinscripción. En el caso de las claves de acceso, los usuarios se autentican desde otro dispositivo sincronizado. En el caso de las credenciales no sincronizadas, use la recuperación por correo electrónico verificado combinada con una comprobación estricta, la recuperación administrativa o la aprobación con dispositivos de confianza.

Las API, ¿autentican a los usuarios directamente?

No. En las arquitecturas de identidad modernas, el proveedor de identidad se encarga de la autenticación y emite tokens. Las API validan los tokens de acceso y hacen cumplir la autorización. Las API no participan en el proceso de autenticación.

¿Puede funcionar el acceso sin contraseña en entornos empresariales?

Sí. Muchas empresas combinan con éxito WebAuthn con el inicio de sesión único (SSO) y los controles de gestión de dispositivos. En los casos de uso empresariales, suelen preferirse las credenciales WebAuthn no sincronizadas, vinculadas a dispositivos gestionados con señales basadas en el riesgo.

La autenticación sin contraseña es fundamental para cerrar las brechas de seguridad más comunes en las aplicaciones. La implementación de métodos resistentes al phishing, como WebAuthn y las claves de acceso, requiere una plataforma de identidad fuerte.

El uso de un servicio como Auth0 puede simplificar la autenticación sin contraseña, lo que permite a los desarrolladores centrarse en las funciones principales de las aplicaciones. Explore nuestra serie de Introducción a la IAM para conocer más temas relacionados con la gestión de identidades y accesos.

Más información

Estos materiales tienen únicamente fines informativos generales. Usted es responsable de obtener orientación de seguridad, de privacidad, de cumplimiento o empresarial de sus propios asesores profesionales, y no debe confiar solamente en la información suministrada aquí.