¿Qué es WebAuthn? Definición, ejemplos y mejores prácticas

WebAuthn es el estándar del W3C para la autenticación sin contraseña y resistente al phishing. Descubra cómo funciona, los errores comunes de implementación y las mejores prácticas empresariales.

¿Qué es WebAuthn?

Las contraseñas fallan. Son objeto de phishing, stuffing, spraying y volcado. El Data Breach Investigations Report (DBIR) 2026 de Verizon encontró abuso de credenciales en el 39% de todas las brechas, la técnica individual más generalizada en su conjunto de datos, por lo que los defensores priorizan controles que eliminen las contraseñas de la ruta de inicio de sesión. WebAuthn es el estándar del World Wide Web Consortium (W3C) creado para hacer exactamente eso.

WebAuthn, abreviatura de Web Authentication, es un estándar web del W3C que define una API del navegador para crear y usar credenciales sólidas basadas en clave pública para autenticar usuarios en aplicaciones web. En lugar de intercambiar secretos compartidos como contraseñas, WebAuthn utiliza criptografía asimétrica: su autenticador genera un par de claves único por sitio, mantiene la clave privada bloqueada dentro de hardware seguro y solo comparte la clave pública con el servidor.

La especificación del W3C lo define formalmente como "una API que permite la creación y el uso de credenciales sólidas, atestiguadas, delimitadas y basadas en clave pública por parte de aplicaciones web, con el propósito de autenticar sólidamente a los usuarios". En términos prácticos, esto significa que puede iniciar sesión en aplicaciones web usando un escaneo de huella digital, desbloqueo facial o una llave de seguridad física, y el servidor nunca recibe nada que un atacante pueda reutilizar.

WebAuthn es un componente central del proyecto FIDO2, desarrollado en coordinación con la Fast Identity Online (FIDO) Alliance. FIDO2 combina WebAuthn (la capa de API del navegador) con CTAP (Client to Authenticator Protocol), que gestiona la comunicación entre su dispositivo autenticador y el navegador a través de USB, comunicación de campo cercano (NFC) o Bluetooth Low Energy (BLE). Juntos, forman la base de la autenticación sin contraseña y resistente al phishing en la web.

Dos incidentes muestran lo que cuesta el modelo de contraseñas a escala. En 2021, los atacantes accedieron a Colonial Pipeline a través de un perfil heredado de red privada virtual (VPN) que no estaba destinado a estar en uso, según declaró el CEO de la empresa al Senado de EE. UU.. Colonial cerró el oleoducto para contener el ataque y pagó un rescate de 4,4 millones de dólares a un afiliado de DarkSide, la operación de ransomware cubierta en un aviso de CISA. Posteriormente, el Department of Justice incautó 2,3 millones de esa cantidad. En 2023, MGM Resorts informó un impacto financiero negativo estimado de 100 millones de dólares por un incidente cibernético que comenzó con ingeniería social contra flujos de trabajo de identidad, según un 8-K de octubre de 2023. Ambos incidentes dependieron de un secreto reutilizable. WebAuthn lo elimina de la ruta de inicio de sesión.

WebAuthn frente a la autenticación tradicional

La autenticación tradicional se basa en secretos compartidos. Las contraseñas, los códigos de un solo uso y las aprobaciones push transmiten datos que un atacante puede interceptar, reproducir o suplantar mediante phishing en tiempo real. WebAuthn cambia el modelo al sustituir los secretos compartidos por criptografía de clave pública, donde la clave privada nunca sale del hardware de su autenticador y nada reutilizable cruza la red.

Las diferencias importan más en los puntos donde los métodos tradicionales fallan:

• Resistencia al phishing. La autenticación basada en contraseñas y OTP puede ser capturada por proxies de phishing en tiempo real. Las credenciales WebAuthn están vinculadas criptográficamente al dominio de origen, por lo que una credencial registrada en login.example.com no se autenticará contra login-example.com ni contra ningún otro dominio similar. El navegador aplica esto a nivel de protocolo, independientemente del criterio del usuario.
• Exposición del lado del servidor. Los sistemas tradicionales almacenan hashes de contraseñas o secretos compartidos que se convierten en objetivos de alto valor en brechas de bases de datos. WebAuthn almacena solo claves públicas. Un compromiso completo del servidor no le da a un atacante nada que pueda usar para suplantar a un usuario.
• Reutilización de credenciales. Los usuarios reutilizan contraseñas entre servicios, lo que hace que el credential stuffing sea eficaz a escala. WebAuthn genera un par de claves único por parte confiable, por lo que una credencial comprometida en un servicio no tiene ningún valor en otro.
• Fricción del usuario frente al equilibrio de seguridad. Las contraseñas más largas y la rotación frecuente mejoran la seguridad en teoría, pero degradan la usabilidad. WebAuthn elimina ese equilibrio: un escaneo de huella digital o desbloqueo facial proporciona una garantía de autenticación más sólida que cualquier política de contraseñas, con menos fricción para el usuario.

El efecto neto es que WebAuthn elimina los tres vectores responsables de la mayoría de las brechas basadas en credenciales: phishing, robo del lado del servidor y reutilización entre sitios. Comprender estas diferencias sienta las bases para entender cómo los componentes del protocolo aplican esas propiedades.

Componentes clave de WebAuthn

WebAuthn opera sobre una arquitectura de tres partes definida por la especificación del W3C.

Autenticador: Esta es la entidad criptográfica que genera pares de claves y firma aserciones de autenticación. Los autenticadores se dividen en dos categorías:

• Autenticadores de plataforma están integrados en el sistema operativo de su dispositivo: Windows Hello, Touch ID, Face ID. Se registran con casi ninguna fricción, pero se pierden si se pierde el dispositivo.
• Autenticadores itinerantes (multiplataforma) son dispositivos de hardware portátiles como YubiKeys y llaves de seguridad FIDO. Funcionan en múltiples dispositivos, pero requieren distribución física y gestión de inventario.

Independientemente del tipo que elija, el modelo de seguridad sigue siendo el mismo: el autenticador crea un par de claves único por parte confiable, y la clave privada nunca sale del límite seguro del autenticador.

Relying Party (RP): Esta es su aplicación web: JavaScript del lado del cliente que invoca la API de WebAuthn más un componente del lado del servidor que gestiona el almacenamiento y la verificación de credenciales. El RP almacena solo la clave pública. El ID de RP, normalmente su nombre de dominio, sirve como ancla criptográfica para la vinculación al origen.

User Agent (navegador): El navegador media todas las interacciones entre autenticadores y partes confiables. Aplica políticas de origen, evita el uso indebido de credenciales entre dominios y preserva la privacidad del usuario: las credenciales registradas en un origen no pueden ser utilizadas por otro, lo que es lo que detiene el phishing a nivel de protocolo.

WebAuthn también define un marco de atestación que permite a los autenticadores demostrar criptográficamente su autenticidad durante el registro. Su empresa puede entonces verificar que las credenciales provienen de modelos de autenticadores confiables y aprobados por TI, en lugar de dispositivos desconocidos o de consumo. El FIDO Metadata Service proporciona un mecanismo activo de revocación y avisos para modelos de autenticadores.

Una vez que conoce los actores y los límites de confianza, puede mapear las dos ceremonias y ver exactamente dónde puede fallar la verificación.

Cómo funciona WebAuthn

WebAuthn define dos ceremonias criptográficas: registro (creación de credenciales) y autenticación (verificación de aserciones). Ambas siguen un protocolo de desafío-respuesta.

1. Registro (creación de credenciales): Su servidor genera un desafío aleatorio criptográficamente seguro y lo envía al cliente junto con información de la parte confiable, detalles de la cuenta de usuario y algoritmos criptográficos aceptables. El cliente llama a navigator.credentials.create(). El autenticador solicita el consentimiento explícito del usuario, genera un nuevo par de claves asimétricas y devuelve un objeto de atestación que contiene la clave pública, el desafío firmado, el ID de credencial y (opcionalmente) una cadena de certificados de atestación. Su servidor verifica la atestación, valida la firma, confirma que la clave pública coincide con los algoritmos solicitados y almacena la clave pública de la credencial, el ID de credencial y el contador de firmas. Protección crítica: incluso con parámetros idénticos, navigator.credentials.create() genera una nueva credencial en cada llamada. Debe usar el parámetro excludeCredentials para evitar registros duplicados.
2. Autenticación (verificación de aserciones): Su servidor genera un nuevo desafío y lo envía al cliente con una lista de IDs de credenciales permitidos. El cliente llama a navigator.credentials.get(). El autenticador verifica la presencia o identidad del usuario (según su política) y luego firma el desafío con la clave privada almacenada. Su servidor recupera la clave pública almacenada, verifica la firma de la aserción, valida la coincidencia del desafío, comprueba los indicadores de presencia/verificación del usuario, confirma que el origen y el ID de RP coinciden y verifica que el contador de firmas se haya incrementado.

La verificación del contador de firmas es su defensa contra autenticadores clonados. Si el contador no se incrementa como se espera, tiene evidencia de duplicación de credenciales.

Para el cumplimiento de AAL2, debe aplicar User Verification (UV), no solo User Presence (UP). Según la guía sobre autenticadores sincronizables, los verificadores deben indicar que se prefiere UV e inspeccionar las respuestas para confirmar que el indicador UV está establecido.

Cómo implementan WebAuthn las organizaciones

Ver dónde se ejecuta WebAuthn en producción responde a la pregunta que la mayoría de los evaluadores realmente hacen: ¿se ha demostrado esto a escala?

• Google Accounts es el punto de referencia más claro. Google comenzó a implementar passkeys en mayo de 2023 y las convirtió en la opción predeterminada para cuentas personales en octubre de 2023. En el plazo de un año desde el lanzamiento, las passkeys se habían utilizado más de mil millones de veces en más de 400 millones de cuentas, y Google informó que las passkeys ya se usaban para autenticación con más frecuencia que SMS OTP y las aplicaciones autenticadoras combinadas en una base diaria.
• GitHub citó WebAuthn como la opción de 2FA más sólida disponible cuando impuso 2FA en 2023 para todos los colaboradores, calificando las llaves de seguridad físicas y los autenticadores de plataforma como Windows Hello y Face ID como los métodos menos vulnerables al phishing.
• Las plataformas comerciales han seguido el ejemplo: Amazon, PayPal, Shopify, DocuSign y Kayak, que redujo el tiempo promedio de registro e inicio de sesión en un 50%, ya han lanzado inicio de sesión respaldado por WebAuthn. Estas implementaciones confirman que WebAuthn funciona a escala de consumidor, gestiona flujos de recuperación y se integra con arquitecturas estándar de proveedores de identidad.

Una vez comprendidas las ceremonias y las implementaciones del mundo real, la siguiente decisión es qué tipo de autenticador se adapta a su entorno.

Tipos de autenticadores WebAuthn

La elección del autenticador determina el nivel de garantía de seguridad, la experiencia del usuario y la sobrecarga operativa de su implementación de WebAuthn. Cada tipo conlleva compensaciones distintas que importan para la planificación empresarial.

1. Los autenticadores de plataforma están integrados en el sistema operativo y el hardware del dispositivo. Windows Hello utiliza un PIN respaldado por Trusted Platform Module (TPM), reconocimiento facial o huella digital. Los dispositivos Apple usan Touch ID o Face ID respaldados por Secure Enclave. Los dispositivos Android usan huella digital o desbloqueo facial a través de Google Play Services. Los autenticadores de plataforma 1carry la menor fricción de inscripción porque los usuarios ya tienen el hardware, y la verificación biométrica satisface los requisitos de verificación del usuario (UV) para el cumplimiento de AAL2 sin pasos adicionales. La limitación es que las credenciales están vinculadas al dispositivo. Si un usuario pierde su portátil o teléfono, esas credenciales desaparecen a menos que use passkeys sincronizadas.
2. Los autenticadores itinerantes (multiplataforma) son tokens de hardware portátiles, como YubiKeys, llaves Feitian BioPass u otras llaves de seguridad FIDO2, que se conectan por USB, NFC o BLE. Funcionan en múltiples dispositivos y sistemas operativos, lo que los convierte en la opción estándar para acceso privilegiado, entornos de estaciones de trabajo compartidas y casos de uso de alta garantía. La compensación está en la logística de distribución: necesita adquirir, enviar, inventariar y gestionar dispositivos físicos, y los usuarios deben llevarlos consigo.
3. Las passkeys sincronizadas son una categoría más reciente en la que las credenciales WebAuthn se sincronizan a través de un gestor de contraseñas de plataforma (iCloud Keychain, Google Password Manager o un gestor de terceros como 1Password). Las passkeys sincronizadas reducen el problema de recuperación por pérdida del dispositivo porque la credencial sobrevive en cualquier dispositivo conectado a la misma cuenta. Para la mayoría de los usuarios empresariales, esto elimina el mayor punto de fricción en la adopción de WebAuthn. La compensación es que la seguridad de su autenticación ahora depende parcialmente de la seguridad de la cuenta de plataforma que aloja la credencial sincronizada. Para entornos de alta garantía, las credenciales vinculadas al dispositivo con llaves de respaldo gestionadas por TI siguen siendo la opción más sólida.

La mayoría de las implementaciones empresariales usan una combinación: autenticadores de plataforma para el uso diario, una llave itinerante como respaldo registrado y passkeys sincronizadas donde el perfil de riesgo lo permita. Elegir la combinación correcta depende de sus requisitos de garantía, su población de usuarios y cuánta sobrecarga operativa puede absorber.

La decisión sobre el autenticador influye directamente en las propiedades de seguridad que obtiene, que es lo que cubre la siguiente sección.

Beneficios de seguridad de WebAuthn

WebAuthn ofrece ventajas de seguridad concretas en resistencia al phishing, exposición del lado del servidor, cumplimiento normativo y prevención de ataques entre sitios:

• Resistencia al phishing a nivel de protocolo. WebAuthn vincula las credenciales criptográficamente al origen. El comentario de FIDO Alliance a NIST advirtió que los atacantes ya han alcanzado a los autenticadores AAL2 que no son resistentes al phishing. WebAuthn cierra esa brecha.
• Sin secretos compartidos en el servidor.El modelo de criptografía de clave pública de FIDO2 elimina la necesidad de compartir secretos entre el proveedor de identidad y el autenticador, lo que NIST SP 800-63B-4 denomina resistencia al compromiso del verificador. Una brecha completa de base de datos no produce nada que un atacante pueda reproducir.
• Alineación normativa. WebAuthn satisface los requisitos resistentes al phishing de AAL2 de NIST SP 800-63B-4. El memorando M-22-09 de la Office of Management and Budget (OMB) del gobierno de EE. UU. menciona directamente el estándar Web Authentication del W3C como un enfoque resistente al phishing para agencias federales. Las organizaciones reguladas obtienen una ruta de cumplimiento clara y auditable.
• Eliminación de ataques del elemento humano. El DBIR 2026 de Verizon   situó el elemento humano en el 62% de las brechas. WebAuthn elimina dos superficies críticas de ataque humano: la selección de contraseñas débiles y la susceptibilidad al phishing. Los usuarios no pueden elegir malas contraseñas cuando no hay contraseñas.
• Prevención de credential stuffing entre sitios. Cada credencial está delimitada criptográficamente a un dominio específico, lo que hace que el credential stuffing sea mucho menos eficaz entre servicios.

Estas propiedades de seguridad no son teóricas. Las organizaciones que han implementado WebAuthn a escala ya las han validado en producción, y los casos de uso abarcan casi todos los sectores verticales.

Casos de uso comunes de WebAuthn

La adopción de WebAuthn se concentra en escenarios donde los ataques basados en credenciales tienen el mayor impacto empresarial. Estos son los patrones de implementación que aparecen con más frecuencia en entornos de producción.

• Acceso privilegiado y consolas de administración. Los portales VPN, las consolas de gestión en la nube y los paneles de administración de infraestructura son los objetivos de mayor valor para el robo de credenciales. Implementar WebAuthn como segundo factor obligatorio, o como método principal sin contraseña, para estos puntos de acceso elimina la superficie de ataque que los kits de phishing y los volcados de credenciales explotan con mayor agresividad. Esta suele ser la primera fase en cualquier despliegue empresarial.
• Inicio de sesión orientado al cliente para servicios financieros y atención sanitaria. Las industrias reguladas donde el compromiso de credenciales desencadena notificación de brechas, sanciones regulatorias y pérdidas financieras directas están adoptando passkeys para la autenticación de clientes. Las aplicaciones bancarias, los portales de pacientes y las plataformas de seguros usan WebAuthn para satisfacer tanto los requisitos de cumplimiento (PCI DSS, controles de acceso HIPAA) como el objetivo operativo de reducir el fraude por toma de control de cuentas.
• Entornos de estaciones de trabajo compartidas y quioscos. Hospitales, plantas de fabricación y operaciones minoristas ejecutan terminales compartidos donde el inicio de sesión basado en contraseñas es lento y propenso al shoulder-surfing. Los autenticadores itinerantes (llaves de seguridad habilitadas para NFC o soluciones de toque de credencial) autentican a los usuarios en segundos sin introducir credenciales en un dispositivo compartido.
• Inicio de sesión único (SSO) para la fuerza laboral. Implementar WebAuthn a nivel del proveedor de identidad (IdP), mediante plataformas como Okta, Azure AD o Ping Identity, protege cada aplicación descendente en un entorno federado con una sola inscripción. Esta es la ruta más eficiente hacia una cobertura amplia porque implementa WebAuthn una vez en el IdP y cada parte confiable de Security Assertion Markup Language (SAML) u OpenID Connect (OIDC) hereda la autenticación resistente al phishing.

Cada uno de estos casos de uso refuerza el mismo principio: cuanto más se acerque a eliminar secretos reutilizables de su flujo de autenticación, menos rutas de ataque basadas en credenciales permanecerán abiertas. Dicho esto, implementar WebAuthn a escala introduce complejidad operativa que los equipos deben planificar.

Desafíos y limitaciones de WebAuthn

El modelo de seguridad de WebAuthn es sólido, pero las implementaciones empresariales revelan una complejidad operativa que los equipos subestiman de forma sistemática:

• Gestión del ciclo de vida de credenciales. El principal modo de fallo en las implementaciones empresariales de WebAuthn es operativo, no criptográfico. Necesita procesos documentados para la distribución de autenticadores, revocación de credenciales por pérdida de dispositivo, políticas de renovación y soporte al usuario ante fallos de autenticación. La guía de ciclo de vida de FIDO cubre en detalle las fases de inscripción, recuperación y revocación.
• Selección del tipo de autenticador. Se enfrenta a una decisión estratégica entre autenticadores de plataforma (coste de distribución cero, se pierden con el dispositivo), autenticadores itinerantes (portátiles pero que requieren distribución física) y enfoques híbridos. Cada uno conlleva distintos niveles de garantía, requisitos de recuperación y sobrecarga operativa.
• Integración con aplicaciones heredadas. No todas las aplicaciones de su entorno admiten WebAuthn de forma nativa. Necesita abordar la integración con protocolos de federación como SAML, OAuth y OpenID Connect. Esto representa un desafío importante para organizaciones con topologías complejas de federación de identidad.
• Decisiones de arquitectura del servidor FIDO. Debe elegir entre integrar un servidor FIDO en su proveedor de identidad existente, implementar un servidor FIDO independiente o usar un modelo de FIDO-server-as-a-service. Cada opción afecta la arquitectura de almacenamiento de credenciales, los procedimientos de recuperación ante desastres y el alcance del despliegue. La guía de implementación de servidores FIDO cubre en detalle las compensaciones.
• La compensación de las credenciales sincronizadas. La sincronización de passkeys a través de los principales gestores de contraseñas de plataforma reduce drásticamente la fricción del usuario, pero transfiere una parte de la seguridad de autenticación a la seguridad de la cuenta de plataforma. Donde los requisitos de garantía son más altos, las credenciales vinculadas al dispositivo con llaves de respaldo gestionadas por TI siguen siendo la opción más sólida.

Más allá de la complejidad operativa, decisiones específicas de implementación crean una exposición más duradera:

• Tratar toda MFA como resistente al phishing. Este es el error de mayor impacto. Implementar TOTP, SMS OTP o MFA por notificación push y afirmar cumplimiento resistente al phishing lo deja expuesto. Los proxies de phishing en tiempo real capturan y reproducen ambos factores en estos enfoques. Solo WebAuthn con vinculación del nombre del verificador o vinculación de canal logra una verdadera resistencia al phishing.
• Permitir el registro de credenciales sin autenticación. CVE-2021-3632 demostró esto en Keycloak, donde cualquiera podía registrar un nuevo dispositivo de seguridad cuando no existía ningún dispositivo para una cuenta de usuario. El registro debe ocurrir dentro de una sesión ya autenticada o mediante procesos fuera de banda verificados.
• Diseño deficiente del flujo de inscripción. Una inscripción torpe genera resistencia del usuario y aumenta el volumen de tickets de soporte. Su portal de inscripción debe guiar a los usuarios a través del registro dentro de una sesión autenticada, proporcionar instrucciones claras sobre autenticadores aceptables y explicar por qué se rechazaron dispositivos específicos.
• Falta de mecanismos de respaldo y recuperación. Implementar WebAuthn sin procedimientos documentados de respaldo para pérdida de dispositivo, fallo de hardware o problemas biométricos crea escenarios de bloqueo. Necesita autenticadores de respaldo prerregistrados, códigos de acceso de emergencia para administradores de TI y procesos de verificación en persona.
• Implementar WebAuthn de forma aislada de su pila de seguridad. WebAuthn no es una solución independiente. Según NIST SP 1800-35, debe integrarse con evaluación continua de autenticación, verificación del estado del dispositivo, políticas de acceso con reconocimiento de contexto y su infraestructura de seguridad de endpoints. En una arquitectura zero trust, WebAuthn se convierte en una de las señales más sólidas que puede incorporar en las decisiones de acceso.

Estos desafíos se pueden resolver con la planificación adecuada. Las siguientes prácticas cubren las decisiones clave que separan una implementación lista para producción de una prueba de concepto.

Prácticas recomendadas para implementar WebAuthn

Las siguientes prácticas cubren las decisiones clave que separan una implementación de WebAuthn lista para producción de una prueba de concepto.

Aplique la verificación del usuario para AAL2. Establezca userVerification: "required" tanto en las ceremonias de registro como de autenticación y valide el indicador UV del lado del servidor. No confíe en "preferred" para implementaciones con alcance de cumplimiento.

Use la atestación para aplicar la política del autenticador. Compruebe las atestaciones durante el registro y permita solo autenticadores que cumplan sus requisitos de seguridad (por ejemplo, certificación FIDO L1+). Use listas de permitidos basadas en AAGUID (identificador de modelo de autenticador) e intégrese con el FIDO Metadata Service para comprobaciones activas del estado del autenticador.

Implemente por fases. La recomendación de despliegue por fases de FIDO es un enfoque escalonado:

1. WebAuthn como segundo factor para aplicaciones de alto riesgo (VPN, acceso privilegiado, consolas de administración)
2. Despliegue de segundo factor en toda la plataforma mientras se construye soporte operativo
3. Credenciales detectables y flujos sin contraseña para poblaciones de usuarios maduras
4. Sin contraseña completo con autenticación heredada retirada para usuarios inscritos

Este enfoque le permite validar políticas, soporte y flujos de recuperación antes de convertir WebAuthn en la opción predeterminada.

Implemente una estrategia de recuperación con múltiples autenticadores. Registre al menos dos autenticadores por usuario: uno principal (por ejemplo, autenticador de plataforma para uso diario) y uno de respaldo (por ejemplo, llave de seguridad almacenada de forma segura). Muestre claramente las credenciales de recuperación registradas en la configuración de la cuenta del usuario.

Verifique los contadores de firmas. Compruebe que el contador de firmas se incremente de forma monótona en cada autenticación. Un contador que no se incrementa indica un autenticador potencialmente clonado.

Separe los errores esperados de los inesperados. Realice un seguimiento explícito de los errores de WebAuthn. Agrupe NotAllowedError, AbortError y los errores de passkey de Credential Manager como señales distintas para poder diferenciar la fricción del usuario de las anomalías de seguridad.

Seguir estas prácticas llevará su implementación de WebAuthn a un estado listo para producción. Pero incluso un despliegue de WebAuthn correctamente configurado no es una defensa de identidad completa. Los ataques que eluden WebAuthn por completo requieren controles que operen más allá de la ceremonia de inicio de sesión: secuestro de sesión, movimiento lateral posterior a la autenticación e ingeniería social al servicio de asistencia.

Cómo SentinelOne mejora la seguridad de identidad

WebAuthn reduce la reproducción de credenciales, pero no detiene todos los ataques por la ruta de identidad que verá en producción. Aún necesita gestionar el robo de tokens de sesión, el compromiso del dispositivo, la ingeniería social al servicio de asistencia y el movimiento lateral posterior a la autenticación.

La Singularity™ Platform cierra esa brecha al correlacionar el contexto de identidad y endpoint:

• Singularity Identity detecta comportamiento sospechoso de identidad y responde cuando los adversarios apuntan a servicios de directorio y flujos de trabajo de SSO. Cubre la infraestructura de identidad que WebAuthn nunca toca.
• Singularity Endpoint ejecuta modelos de IA conductuales y estáticos en el dispositivo para detener malware de robo de credenciales y actividad hands-on-keyboard que elude por completo los controles de inicio de sesión. Señala patrones maliciosos en tiempo real sin intervención humana, lo cual importa cuando los atacantes van tras las sesiones en lugar de las contraseñas.
• Purple AI™ razona sobre sus datos de seguridad para guiar investigaciones y recomendar las siguientes acciones. Un IDC Snapshot de 2025 encontró que los clientes identificaban amenazas un 63% más rápido, lo cual importa cuando necesita determinar si un inicio de sesión fallido de WebAuthn fue fricción del usuario o una campaña activa de phishing.

Juntos, contienen la ruta de ataque de identidad a ambos lados del inicio de sesión.

Si trata WebAuthn como una señal sólida dentro de su programa más amplio de defensa contra phishing y flujo de trabajo de respuesta a incidentes, puede reducir tanto el riesgo de toma de control como el tiempo que dedica a demostrar lo que ocurrió.

Solicite una demostración para ver cómo SentinelOne cierra la brecha entre la autenticación y una defensa de identidad completa.

Realizar el recorrido

Obtenga protección de identidad en tiempo real y visibilidad de extremo a extremo en entornos híbridos para detectar exposiciones, detener el abuso de credenciales y reducir el riesgo de identidad.

Conclusiones clave

WebAuthn es el estándar del W3C para autenticación web sin contraseña y resistente al phishing mediante criptografía de clave pública. Vincula las credenciales criptográficamente a dominios específicos, haciendo que la reproducción de credenciales sea arquitectónicamente imposible. 

Una implementación empresarial exitosa requiere un despliegue por fases, política de autenticadores basada en atestación, estrategias de recuperación multidispositivo e integración con su pila de seguridad más amplia.

Preguntas frecuentes

¿Qué es WebAuthn en ciberseguridad?

WebAuthn, abreviatura de Web Authentication, es un estándar web del W3C que define una API del navegador para crear y usar credenciales sólidas basadas en clave pública para autenticar a los usuarios en aplicaciones web. 

En lugar de contraseñas, utiliza criptografía asimétrica: su autenticador genera un par de claves único por sitio, mantiene la clave privada en hardware seguro y comparte solo la clave pública con el servidor. Esto hace que el robo de credenciales y los ataques de phishing sean mucho más difíciles de ejecutar.

¿Qué ataques previene WebAuthn?

La principal propiedad de seguridad de WebAuthn es la resistencia al phishing mediante la vinculación criptográfica al dominio. Cuando registras una credencial, esta se vincula al origen exacto de la parte confiante. Cuando te autenticas, el navegador incluye criptográficamente ese origen en la respuesta firmada, por lo que un atacante en un dominio similar no puede reutilizar tu credencial. 

Más allá del phishing, WebAuthn elimina el robo de credenciales del lado del servidor porque solo se almacenan claves públicas, y detiene el relleno de credenciales porque cada credencial está limitada a un único dominio.

¿Es WebAuthn lo mismo que FIDO2?

WebAuthn y FIDO2 están relacionados, pero no son idénticos. FIDO2 es el proyecto más amplio, desarrollado por la FIDO Alliance en coordinación con el W3C, que combina dos especificaciones: WebAuthn (la API del navegador para crear y verificar credenciales de clave pública) y CTAP (Client to Authenticator Protocol, que gestiona la comunicación entre su autenticador y el navegador a través de USB, NFC o BLE). 

WebAuthn es la mitad de FIDO2 orientada a la web. Usted implementa WebAuthn en su aplicación. CTAP se ejecuta entre el hardware del autenticador y el navegador.

¿Cómo admite WebAuthn la seguridad Zero Trust?

WebAuthn proporciona una de las señales de autenticación más sólidas en una arquitectura de confianza cero. Según NIST SP 1800-35, se integra con la evaluación continua de la autenticación, la verificación del estado del dispositivo y las políticas de acceso con reconocimiento del contexto. Debido a que las credenciales de WebAuthn son resistentes al phishing y están vinculadas al dominio, sirven como un paso de verificación de identidad de alta garantía que alimenta decisiones de acceso más amplias. 

En la práctica, combinar WebAuthn con telemetría de endpoints y análisis del comportamiento proporciona a su motor de políticas una señal de autenticación más confiable que cualquier contraseña o método de MFA heredado.

¿Qué navegadores y plataformas admiten WebAuthn?

Según Can I Use, WebAuthn está disponible en aproximadamente el 95% de los navegadores globales. Todos los navegadores de escritorio evergreen lo admiten: Chrome (v67+), Firefox (v60+), Safari (v14+) y Edge (v18+). En dispositivos móviles, Chrome para Android, Safari en iOS y Samsung Internet admiten WebAuthn. 

En cuanto a los autenticadores de plataforma, Windows 10+ incluye Windows Hello (reconocimiento facial, huella digital, PIN mediante TPM), macOS/iOS 16+ admite Touch ID y Face ID con sincronización de iCloud Keychain para passkeys, y Android 9+ proporciona desbloqueo por huella digital y reconocimiento facial mediante Google Play Services. Siguen existiendo brechas en versiones anteriores de sistemas operativos y en algunas configuraciones empresariales de navegadores con restricciones.

¿Cuál es la diferencia entre WebAuthn y las passkeys?

WebAuthn es la especificación de la API del W3C que los navegadores implementan para la creación y autenticación de credenciales de clave pública. Las passkeys son un término orientado al usuario para las credenciales de WebAuthn, y a menudo se refiere específicamente a credenciales sincronizadas (respaldadas en la nube) que se sincronizan entre sus dispositivos a través de proveedores de plataforma. 

Todas las passkeys usan WebAuthn internamente, pero no todas las credenciales de WebAuthn son passkeys sincronizadas. Las credenciales de WebAuthn vinculadas al dispositivo permanecen asociadas a hardware específico.

¿Puede WebAuthn reemplazar todas las formas de MFA?

WebAuthn puede funcionar como autenticación de un solo factor (posesión del autenticador), de dos factores (posesión más biometría o PIN) o multifactor, según su configuración. 

Para cumplir con AAL2, debe aplicar la verificación del usuario (biometría o PIN) y validar del lado del servidor la marca UV. WebAuthn reemplaza los métodos heredados de MFA, como TOTP y SMS OTP, al tiempo que proporciona una mayor resistencia al phishing que cualquiera de ellos.

¿Qué sucede si un usuario pierde su autenticador de WebAuthn?

Sin un plan de recuperación, quedará bloqueado. La mejor práctica es registrar al menos dos autenticadores por usuario: un dispositivo principal para el uso diario y una copia de respaldo almacenada de forma segura. 

Su proceso de recuperación de cuenta también debe incluir códigos de acceso de emergencia para administradores de TI y una vía de verificación en persona para entornos de alta garantía donde los autenticadores de respaldo no estén disponibles.

¿Funciona WebAuthn con sistemas de identidad federada?

Sí, pero la integración requiere planificación. WebAuthn opera en el nivel del proveedor de identidad (IdP) en entornos federados que usan SAML, OAuth u OpenID Connect. Su IdP gestiona la ceremonia de WebAuthn y luego emite tokens de federación a las aplicaciones posteriores. 

Esto significa que implementa WebAuthn en el IdP en lugar de hacerlo en cada aplicación individual, lo que simplifica el despliegue en todos los servicios federados.

¿Cómo protege WebAuthn contra los ataques de intermediario?

El navegador incluye criptográficamente el origen (dominio) en los datos firmados por el autenticador durante cada ceremonia de autenticación. Un atacante de intermediario no puede retransmitir una aserción de autenticación a un dominio diferente porque la firma no se validará para ningún origen distinto de aquel en el que se registró la credencial. 

Esta protección opera a nivel de protocolo, independientemente de TLS o de la concienciación del usuario.