Cómo Funciona el Inicio de Sesión sin Contraseña Internamente
Haces clic en “Iniciar sesión”, tu teléfono solicita tu huella dactilar y quedas autenticado. Sin escribir contraseña, sin copiar código de un correo electrónico. Si has implementado flujos de autenticación antes, esto probablemente te parezca magia—o peor aún, una caja negra que se espera que integres sin entender.
Este artículo explica cómo funcionan realmente las passkeys y WebAuthn por debajo de las APIs del navegador. Comprenderás el flujo de autenticación, las primitivas criptográficas involucradas y las propiedades de seguridad que hacen que la autenticación sin contraseña basada en FIDO2 sea fundamentalmente diferente de enfoques anteriores como los enlaces mágicos o los OTP.
Puntos Clave
- Las passkeys utilizan criptografía de clave pública donde la clave privada nunca abandona tu dispositivo, eliminando secretos compartidos que los atacantes pueden interceptar o robar.
- La autenticación WebAuthn involucra cuatro partes: tu frontend, la API del navegador, el autenticador (llavero del dispositivo o llave de hardware) y tu servidor.
- El enlace de origen proporciona resistencia criptográfica al phishing—las credenciales están vinculadas a dominios específicos y no funcionarán en sitios similares.
- La interfaz condicional permite que las solicitudes de passkey aparezcan en las sugerencias de autocompletado, creando experiencias de autenticación fluidas.
Por Qué las Passkeys Reemplazaron Métodos “Sin Contraseña” Anteriores
Los enlaces mágicos y las contraseñas de un solo uso eliminaron el campo de contraseña de los formularios de inicio de sesión, pero no eliminaron los secretos compartidos. Un enlace mágico sigue siendo un token portador transmitido por correo electrónico—interceptable, reproducible y vulnerable al phishing si los usuarios hacen clic en enlaces en dominios falsificados. Los OTP enviados por SMS son vulnerables a ataques de intercambio de SIM.
Las passkeys resuelven esto de manera diferente. Utilizan criptografía de clave pública donde el secreto (tu clave privada) nunca abandona tu dispositivo y nunca viaja por la red. El servidor solo almacena tu clave pública, que es inútil para los atacantes incluso si la base de datos es comprometida.
Esta es la idea central detrás de FIDO2 y WebAuthn: la autenticación ocurre mediante prueba criptográfica de posesión, no mediante transmisión de secretos.
El Flujo de Autenticación WebAuthn
Cuando un usuario se autentica con una passkey, típicamente interactúan cuatro componentes: tu código frontend, la API WebAuthn del navegador, el autenticador (a menudo el llavero del sistema operativo, un teléfono o una llave de seguridad de hardware) y tu servidor.
Registro: Creación de la Credencial
Durante el registro, tu servidor genera un desafío (challenge)—una secuencia aleatoria de bytes—y lo envía al navegador junto con tu ID de parte confiable (relying party ID, típicamente tu dominio). Tu frontend llama a navigator.credentials.create() con estos parámetros.
El navegador entrega esta solicitud al autenticador a través de CTAP (Client to Authenticator Protocol). El autenticador genera un nuevo par de claves, almacena la clave privada de forma segura y devuelve la clave pública junto con una atestación firmada.
Tu servidor recibe y almacena la clave pública, el ID de credencial y metadatos como un contador de firmas. Sin hash de contraseña, sin secreto compartido—solo una clave pública limitada a tu dominio.
Autenticación: Demostración de Posesión
Cuando el usuario regresa, tu servidor genera un nuevo desafío. Tu frontend llama a navigator.credentials.get(), y el navegador solicita al autenticador.
El autenticador encuentra la credencial que coincide con tu RP ID, requiere verificación del usuario (biométrica, PIN o presencia), luego firma el desafío con la clave privada. Esta firma, junto con los datos del autenticador, regresa a tu servidor.
Tu servidor verifica la firma contra la clave pública almacenada. Si coincide, el usuario demostró que posee la clave privada sin haberla transmitido nunca.
Enlace de Origen: El Mecanismo de Resistencia al Phishing
Esto es lo que hace que las passkeys sean genuinamente resistentes al phishing en lugar de simplemente “más difíciles de phishear”. El autenticador vincula criptográficamente las credenciales al origen de la parte confiable.
Al firmar el desafío, el autenticador incluye el hash del ID de la parte confiable (derivado de tu dominio) en los datos firmados. Si un atacante crea un sitio similar en g00gle.com, la credencial para google.com simplemente no funcionará—los orígenes no coinciden y el autenticador no producirá una firma válida.
Esta no es una advertencia de interfaz que los usuarios puedan ignorar. Se aplica criptográficamente a nivel de protocolo.
Discover how at OpenReplay.com.
Passkeys Sincronizadas vs. Vinculadas al Dispositivo
Las passkeys modernas típicamente se sincronizan entre dispositivos a través de llaveros del sistema operativo—iCloud Keychain de Apple, Google Password Manager o administradores de terceros como 1Password. Esto mejora dramáticamente la usabilidad ya que los usuarios no pierden acceso al cambiar de teléfono.
Las passkeys vinculadas al dispositivo (como las llaves de seguridad de hardware) ofrecen garantías más fuertes—la clave privada existe demostrablemente en exactamente un dispositivo. Para la mayoría de las aplicaciones web, las passkeys sincronizadas proporcionan seguridad suficiente con mejor UX. Tu modelo de amenazas determina cuál importa más.
Patrones Modernos de UX: Interfaz Condicional
Probablemente has visto solicitudes de passkey aparecer en las sugerencias de autocompletado del campo de nombre de usuario. Esta es la interfaz condicional (conditional UI)—el navegador ofrece proactivamente las passkeys disponibles antes de que el usuario solicite explícitamente el inicio de sesión sin contraseña.
Implementa esto llamando a navigator.credentials.get() con mediation: 'conditional' y agregando autocomplete="username" a tu campo de entrada.
El navegador maneja el descubrimiento y la presentación.
Muchas aplicaciones ahora usan la interfaz condicional para actualizar usuarios existentes: después de un inicio de sesión exitoso con contraseña, solicitan a los usuarios que registren una passkey para sesiones futuras.
Propiedades de Seguridad y Límites de Confianza
Las passkeys reducen dramáticamente la superficie de ataque, pero no son mágicas. La seguridad de la clave privada depende de la implementación del autenticador—típicamente el enclave seguro del dispositivo o TPM. Si el dispositivo mismo está comprometido a nivel de hardware, todo está perdido.
La recuperación de cuenta sigue siendo un desafío de diseño. Cuando los usuarios pierden todos sus dispositivos, necesitas mecanismos de respaldo que no reintroduzcan las vulnerabilidades que las passkeys eliminaron.
WebAuthn continúa evolucionando—Level 3 es la generación actual de la especificación—con trabajo continuo en autenticación entre dispositivos y atestación empresarial. Los fundamentos cubiertos aquí permanecen estables.
Conclusión
Las passkeys cambian la autenticación de “verificar que el usuario conoce un secreto” a “verificar que el usuario posee una clave”. Esto cambia tu modelo mental: no estás verificando contraseñas contra hashes, estás verificando firmas criptográficas contra claves públicas.
Para los ingenieros de frontend, la implicación práctica es directa: aprende las ceremonias de registro y autenticación de la API WebAuthn, implementa la interfaz condicional para un descubrimiento fluido y diseña rutas de actualización que muevan a los usuarios de contraseñas a passkeys de manera incremental.
Preguntas Frecuentes
La recuperación de cuenta se vuelve crítica cuando los usuarios pierden todos los dispositivos. Los enfoques comunes incluyen códigos de recuperación de respaldo generados durante el registro, métodos de autenticación secundarios como correo electrónico verificado o procesos de verificación de identidad. El desafío es diseñar respaldos que no reintroduzcan las vulnerabilidades que las passkeys eliminaron, como enlaces mágicos vulnerables al phishing o códigos SMS interceptables.
Sí, las passkeys están diseñadas para compatibilidad multiplataforma. Las passkeys sincronizadas almacenadas en llaveros de plataforma como iCloud Keychain o Google Password Manager funcionan entre dispositivos dentro de ese ecosistema. Para autenticación entre ecosistemas, los usuarios pueden escanear códigos QR para autenticarse usando una passkey almacenada en un dispositivo diferente, aprovechando el protocolo de transporte híbrido FIDO2.
Cada credencial de passkey es única y está vinculada a una cuenta de usuario específica y una parte confiable. Cuando existen múltiples passkeys para el mismo dominio, el navegador o autenticador presenta una interfaz de selección que permite a los usuarios elegir qué credencial usar. El ID de credencial almacenado del lado del servidor mapea cada passkey a su cuenta de usuario correspondiente.
Las passkeys resisten ataques de intermediario mediante el enlace de origen. El autenticador incluye el origen exacto en la respuesta de autenticación firmada. Si un atacante intercepta y retransmite el intento de autenticación a través de un proxy, la discrepancia de origen causa que la verificación de firma falle. El enlace criptográfico hace que los ataques de phishing en tiempo real sean inefectivos.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
