Passkeys y WebAuthn: el recorrido de inicio de sesión en el navegador
Sigue una passkey desde el registro hasta el inicio de sesión, conoce qué verifican el navegador y el servidor y planifica portabilidad, recuperación y alternativas accesibles.
Quieres la documentación estructurada de Identidad?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
El inicio de sesión con passkey es un flujo de autenticación de clave pública coordinado por un sitio, un navegador, un autenticador y un servidor. Durante el registro, el autenticador crea una credencial vinculada a la parte usuaria y el servidor guarda su clave pública. Durante el acceso, el servidor emite un desafío nuevo, el navegador pide a un autenticador disponible que use la clave privada correspondiente y el servidor verifica la respuesta firmada antes de crear una sesión. El navegador ayuda a coordinar la elección del usuario y los límites de seguridad; no decide si la cuenta está autorizada.
La especificación Web Authentication del W3C define las operaciones de credenciales y el modelo de datos del navegador. La guía de MDN sobre Web Authentication explica las interfaces de JavaScript, mientras que la descripción de passkeys de FIDO Alliance explica su uso en dispositivos y gestores de credenciales. Estas fuentes permiten distinguir un medio para demostrar el control de una credencial para un sitio de un documento de identidad portátil o de una garantía de que cualquier dispositivo pueda presentar la misma credencial.
Qué Significa Una Passkey Para El Navegador
Una passkey es una credencial WebAuthn descubrible. Utiliza un par de claves: la clave privada permanece en un autenticador o gestor de credenciales, y la parte usuaria conserva la clave pública asociada y un identificador de credencial. La interfaz WebAuthn del navegador permite que un sitio solicite crear o usar una credencial mediante navigator.credentials.create() y navigator.credentials.get(). El navegador y el autenticador gestionan la ceremonia visible; el sitio aún debe validar el resultado y tomar una decisión sobre la cuenta.
La parte usuaria (RP, por sus siglas en inglés) es el sitio o servicio que solicita autenticar a su usuario. El origen y el RP ID delimitan la credencial WebAuthn. Un sitio no puede pedir sin más que el navegador use la credencial para un origen no relacionado. WebAuthn está diseñado para contextos seguros, con localhost como excepción de desarrollo que tratan los navegadores. Los marcos incrustados o de otro origen tienen restricciones de política adicionales; no obtienen acceso irrestricto a las credenciales por el mero hecho de que la página superior sí lo tenga.
La palabra «passkey» describe una experiencia de credenciales, no una única forma universal de almacenamiento. Un proveedor puede sincronizar una credencial entre dispositivos de la cuenta, dejarla vinculada a un único dispositivo o llave de seguridad, o permitir una ceremonia entre dispositivos. Estas opciones tienen disponibilidad y recuperación distintas. Que exista una API, que haya un autenticador de plataforma o que el navegador devuelva una credencial no establece la identidad legal de alguien, no demuestra quién tocó un dispositivo compartido ni revela si existe una cuenta en un sitio concreto.
También conviene distinguir la presencia del usuario de su verificación. Presencia significa que el autenticador observó una interacción; verificación significa que aplicó una comprobación local, como un PIN, código del dispositivo o dato biométrico. La parte usuaria puede solicitar una preferencia de verificación y debe comprobar que las marcas devueltas satisfacen su política. En una autenticación WebAuthn habitual, el servidor no recibe una plantilla biométrica. Recibe datos del protocolo para verificar la firma y las propiedades de la credencial.
Los sitios deben describir el resultado por etapas. «Passkey disponible» no significa «passkey registrada»; «credencial devuelta» no significa «cuenta autenticada»; y «firma válida» no significa «usuario autorizado para cualquier acción». Separar esas afirmaciones evita exagerar lo ocurrido y ayuda a diagnosticar fallos. Para conocer la privacidad de las señales de capacidad del navegador, consulta la guía sobre fingerprinting de WebAuthn; este artículo se centra en el recorrido de registro, acceso y recuperación. La guía general de inicio con Credential Management cubre contraseñas y credenciales federadas mediadas por el navegador, no los detalles del protocolo WebAuthn.
Registrar Una Credencial Sin Prometer De Más
El registro comienza con una acción clara del usuario, como elegir «Crear una passkey» en la configuración de seguridad de la cuenta. El servidor crea un desafío de registro de corta duración y devuelve las opciones que necesita el navegador: desafío, RP ID y nombre visible, identificador del usuario, algoritmos de clave pública aceptados, preferencias del autenticador y credenciales existentes que se deben excluir. Como una passkey debe ser descubrible, la solicitud debe exigir una credencial descubrible, por ejemplo con authenticatorSelection.residentKey: "required"; no se debe aceptar silenciosamente una credencial no descubrible y llamarla passkey. El servidor controla el desafío y la relación con la cuenta; el cliente no debe inventar ni reutilizar silenciosamente el estado de registro.
La página pasa esas opciones a navigator.credentials.create({ publicKey }). El navegador comprueba si el contexto, las políticas y los autenticadores disponibles permiten la solicitud y después muestra su propia interfaz. El usuario puede elegir un dispositivo o gestor de credenciales, desbloquearlo y confirmar. Con residentKey: "required", el registro debe producir una credencial descubrible o fallar; que una plataforma no pueda satisfacer la solicitud no justifica debilitarla en silencio. La persona puede cancelar, cambiar de método o encontrar una restricción de la plataforma. La página debe tratar todos esos casos como resultados normales y conservar la tarea de configuración de la cuenta.
Si la ceremonia termina correctamente, el navegador devuelve una respuesta de credencial que contiene datos del cliente y un objeto de atestación. La aplicación web envía la respuesta al servidor junto con el estado que identifica el registro pendiente. El servidor comprueba que el desafío coincide y no ha caducado, que el origen está permitido, que el resumen criptográfico del RP ID es el esperado y que la respuesta tiene el tipo y los datos de credencial previstos. También comprueba que la credencial pueda asociarse a la cuenta correcta y que la política de registro exigía una credencial descubrible; cuando la respuesta compatible expone propiedades de la credencial, confirma ese resultado antes de registrarla como passkey. Valida la atestación solo en la medida que lo exige su política documentada.
La atestación puede revelar información sobre la procedencia del autenticador. Un sitio no debe solicitar ni conservar más datos de atestación de los que justifiquen su modelo de amenazas y el aviso al usuario. Muchos servicios de consumo pueden aceptar una gama amplia de autenticadores en vez de identificar modelos. Una política más estrecha puede excluir a usuarios legítimos, crear responsabilidades adicionales sobre los datos y quedar obsoleta cuando cambien las plataformas. Si una empresa tiene un requisito real de garantía, debe explicarlo antes del registro y probar la experiencia en dispositivos compatibles.
Tras validar el registro, el servidor guarda el identificador de credencial, la clave pública, su asociación con la cuenta y solo los metadatos necesarios para verificaciones y gestión futuras. No debe guardar una clave privada: WebAuthn no la devuelve al sitio. Puede haber un contador, pero su comportamiento varía entre autenticadores y credenciales sincronizadas; no trates un valor siempre creciente como un detector universal de robo. Consulta la especificación vigente y el comportamiento documentado del autenticador antes de decidir qué comprobaciones de riesgo aplicar.
Solo cuando el servidor confirma una credencial descubrible según la política de registro debe la página indicar que se añadió la passkey. Si la aplicación no puede confirmar esa propiedad, no llames passkey al resultado; explica que el método no está disponible y ofrece una alternativa clara y compatible. Muestra un nombre comprensible, como «Este dispositivo» o una etiqueta elegida por el usuario, la fecha de alta si resulta útil y una opción para eliminarla o cambiar su nombre. No la etiquetes con datos inferidos sobre el hardware o la identidad. La configuración de seguridad debe explicar que eliminar el registro del sitio quizá no borre la copia gestionada por un proveedor en el ecosistema del dispositivo; es posible que también haya que gestionar esa credencial con el proveedor.
Autenticar Con Un Desafío Nuevo
El inicio de sesión mantiene la misma división de responsabilidades. El usuario elige iniciar sesión con una passkey y el servidor genera un desafío nuevo e impredecible, con una vigencia limitada. También decide el RP ID aceptado, la política de credenciales, los requisitos de verificación del usuario y el contexto de cuenta o transacción que debe vincularse a la ceremonia. En un flujo que pide primero el nombre de usuario, el servidor puede limitar los identificadores permitidos a los asociados con esa cuenta. En un flujo sin nombre de usuario que permite descubrir credenciales, el autenticador puede devolver una credencial y un identificador de usuario que el servidor debe resolver según una política de cuenta explícita.
La página llama a navigator.credentials.get({ publicKey }). El navegador puede mostrar una interfaz de selección de cuenta o autocompletado de passkeys si la plataforma y las reglas de mediación lo permiten. El usuario elige o desbloquea un autenticador, que firma datos del protocolo asociados con el desafío y la parte usuaria. En el uso entre dispositivos, se puede seleccionar el teléfono u otro autenticador desde un navegador distinto mediante una ceremonia mediada. Los detalles dependen del navegador, sistema operativo, proveedor de credenciales y transporte disponible; la aplicación no debe prometer el mismo aviso o transporte en todas las plataformas.
La respuesta de aserción incluye datos del cliente, datos del autenticador, un identificador de credencial y una firma. El servidor verifica que el desafío sea el que emitió, que siga vigente y que no se haya consumido ya. Comprueba el tipo de los datos del cliente, el origen permitido, el resumen criptográfico del RP ID, la asociación entre credencial y cuenta, la firma con la clave pública guardada y el estado de verificación cuando la política lo requiera. Después aplica el estado de la cuenta, la autorización, los límites de frecuencia y las comprobaciones de riesgo antes de crear una sesión. Una firma válida es un elemento de esa decisión, no una sesión por sí misma.
El ciclo de vida del desafío requiere cuidado. Genéralo con una fuente criptográficamente segura, vincúlalo al inicio de sesión o acción sensible correspondiente, haz que caduque pronto y rechaza su reutilización. No lo pongas en URL, analítica ni registros de soporte. Protege el intercambio con el transporte seguro habitual de la aplicación y controles de sesión del servidor. Si falla la verificación, no confíes en un nombre de usuario, etiqueta de credencial o indicador de «éxito» enviado por el navegador.
No confundas detalles de implementación con una persona. Un ID de credencial es un identificador en el sistema de cuentas de una parte usuaria, no una identidad global. El identificador de usuario debe ser opaco y estar limitado al servicio. Una sugerencia de transporte puede ayudar al navegador a elegir una ruta, pero no demuestra que un autenticador esté cerca ni que un dispositivo pertenezca a alguien con nombre. La selección de cuenta y la autorización deben depender de registros del servidor, no de etiquetas de dispositivos o capacidades del navegador.
Planificar Portabilidad Y Recuperación
Algunas passkeys se sincronizan mediante un proveedor entre varios dispositivos del usuario. Los proveedores pueden usar cifrado de extremo a extremo y protecciones de recuperación de cuenta, pero el comportamiento, disponibilidad y configuración exactos varían. Un sitio no debe garantizar que una credencial creada en un teléfono aparezca enseguida en otro, que todo proveedor sea interoperable con cualquier plataforma o que el servicio de sincronización siempre esté disponible. Dirige al usuario a la documentación actual del proveedor para recuperar su cuenta o sincronización; no intentes inspeccionar ni reparar su estado privado.
Otras credenciales quedan vinculadas al dispositivo, por ejemplo, a una llave de seguridad o a un autenticador cuya clave privada no se sincroniza. Pueden ser un segundo factor duradero o una opción controlada por una organización, pero perder o dañar el dispositivo obliga a la parte usuaria a disponer de otra vía de recuperación. La autenticación entre dispositivos es otro caso: la persona usa un dispositivo cercano que guarda la passkey para completar un acceso iniciado en otro lugar. Un código QR o intercambio de proximidad ayuda a establecer la ceremonia, pero no prueba por sí solo que el usuario haya superado la verificación del servidor. No agrupes sincronización, copia de seguridad y uso entre dispositivos bajo una promesa de «funciona en todas partes».
La recuperación de la cuenta y la recuperación del proveedor de credenciales son tareas distintas. La del proveedor restaura el acceso al gestor o al conjunto cifrado de credenciales. La recuperación de la parte usuaria restaura el acceso a una cuenta de servicio cuando no se puede usar ninguna passkey registrada. El sitio normalmente no puede reparar una cuenta de proveedor perdida ni recuperar una clave privada ausente. Su política podría ofrecer otra passkey, una llave de seguridad inscrita, códigos de recuperación, una verificación de identidad aprobada o un proceso de soporte cuidadosamente diseñado. Cada ruta debe tener un nivel de garantía adecuado al valor de la cuenta y a la acción que se recupera.
Ofrece recuperación durante el registro, no solo cuando la persona ya no puede acceder. Recomienda una segunda credencial o método de recuperación apropiado y explica dónde se conserva. En cuentas de alto valor, exige una revisión más fuerte antes de reemplazar todos los autenticadores, cambiar los contactos de recuperación o desactivar un método existente. Cuando la política lo permita, mantén utilizables las credenciales antiguas hasta confirmar el reemplazo e informa claramente al usuario tras cambios de seguridad importantes. El personal de soporte no debe poder omitir las mismas comprobaciones de cuenta solo porque quien llama conozca información pública del perfil.
Las pantallas de recuperación también deben evitar la enumeración de cuentas. Una respuesta pública de acceso o recuperación no debe revelar si un correo o nombre concreto tiene una passkey. En la medida práctica, usa mensajes y tiempos equivalentes; realiza pasos específicos de la cuenta solo después de una verificación adecuada. No registres respuestas de passkey ni secretos de recuperación en analítica, tickets de soporte, capturas de pantalla o texto de errores copiado. Conserva un registro mínimo y auditable de la etapa y el resultado del flujo.
Hacer Accesibles Los Avisos, La Cancelación Y Las Alternativas
El navegador o sistema operativo controla buena parte del aviso del autenticador, pero el sitio es responsable de la experiencia que lo rodea. Explica en lenguaje sencillo qué es una passkey antes de abrir el aviso. Indica la cuenta y acción, avisa que el navegador puede pedir que se seleccione o desbloquee una credencial y mantén disponible una alternativa visible. No inicies una solicitud de credencial solo porque se haya cargado la página o haya vencido un temporizador invisible. Un botón claro y un gesto del usuario hacen que la intención sea comprensible tanto para la persona como para la plataforma.
Trata la cancelación como una decisión del usuario. Si la promesa falla o termina sin una credencial utilizable, déjalo en la página de acceso, conserva los datos que sea seguro mantener y devuelve el foco a un control útil. No vuelvas a abrir el aviso de inmediato, no insistas repetidamente ni anuncies que la cuenta no existe. Distingue cancelación, error de red y rechazo del servidor solo si la aplicación puede hacerlo de manera fiable. Un mensaje general que proteja la privacidad es preferible a revelar estados internos de credencial o cuenta.
Un flujo accesible funciona con teclado, lector de pantalla, ampliación y una interfaz traducida. Usa un botón real con un nombre accesible que describa la acción. Anuncia cambios de estado sin mover el foco de forma inesperada. Asegura que los diálogos y las opciones de cuenta tengan un orden de foco lógico y una forma clara de cerrarlos. No insinúes que las passkeys exigen huella dactilar: una plataforma puede utilizar PIN, código del dispositivo, interacción con una llave de seguridad u otro método local compatible. Incluye instrucciones para quien no pueda utilizar la entrada biométrica principal del dispositivo.
La alternativa debe ser una ruta del producto planificada, no una degradación improvisada. Según el servicio, puede ser otra passkey registrada, una llave de seguridad, una contraseña con autenticación multifactor o recuperación de cuenta. Aplica las mismas reglas de autorización del servidor después de cada método y protege las alternativas contra fuerza bruta y phishing. No cambies de cuenta en silencio después de elegir una passkey ni descartes trabajo sin guardar al cambiar de método. Una alternativa puede ser menos cómoda, pero debe ser comprensible, segura y estar disponible para personas con discapacidades.
Los diagnósticos operativos pueden registrar etapas generales como opciones emitidas, ceremonia cancelada, aserción recibida, verificación rechazada por el servidor y sesión establecida. No registres el desafío, la respuesta de credencial, la firma, datos privados, todos los datos del cliente ni un identificador de usuario sin procesar. Así se obtiene información útil de fiabilidad sin convertir la telemetría de acceso en un sistema de recopilación de credenciales. Antes de publicar, revisa el periodo de conservación, los controles de acceso y si algún indicador puede asociarse a una persona.
Mantener La Privacidad Y La Política Del Servidor En Su Lugar
La vinculación al origen y al RP ID de WebAuthn ayuda a impedir que una credencial creada para una parte usuaria se utilice como si perteneciera a otra. Eso no convierte automáticamente cualquier sistema de autenticación en seguro. El servidor aún necesita gestionar bien los desafíos, mantener listas de orígenes permitidos, usar cookies de sesión seguras, comprobar autorizaciones, limitar frecuencias, definir recuperación y supervisar el sistema. El robo de una sesión activa es distinto al robo de una clave privada de passkey, por lo que la seguridad de la cuenta debe cubrir tanto el ciclo de vida de la credencial como el de la sesión posterior al acceso.
Minimiza las señales que se recopilan durante la ceremonia. No tomes huellas de modelos de autenticador, no guardes la disponibilidad de la API como identidad del dispositivo, no deduzcas el nombre de alguien a partir de un selector de cuentas ni construyas un perfil entre sitios con sugerencias de transporte. Las comprobaciones de capacidad del navegador sirven para decidir si mostrar una acción durante la interacción actual. No son una base para descubrir cuentas, puntuar elegibilidad ni hacer afirmaciones sobre quien sostiene el dispositivo. Solicita solo las opciones de protocolo que necesita el servicio y explica cualquier política de autenticador más limitada antes de que el usuario la encuentre.
Los equipos de implementación deben probar el recorrido completo en las combinaciones de navegador y sistema operativo que realmente admiten: registro, acceso correcto, credencial ausente o rechazada, desafío caducado, origen incorrecto, rechazo del servidor, uso desde otro dispositivo, eliminación y recuperación. Prueba también con teclado y lector de pantalla, además de interacción táctil. Las notas de compatibilidad cambian; consulta la documentación actual de WebAuthn y los datos de compatibilidad del navegador antes de prometer algo. Una demostración correcta en un dispositivo prueba solo esa ruta concreta, no el comportamiento universal.
BotBrowser permite a los equipos revisar su propia interfaz de registro y acceso con passkey usando perfiles de navegador repetibles en sistemas operativos anfitriones compatibles. BotBrowser no controla directamente la mediación del navegador, los autenticadores del sistema operativo, las comprobaciones biométricas locales ni las decisiones del servidor; tampoco crea, guarda, sincroniza, recupera ni autentica passkeys. Úsalo para comparar un flujo autorizado y trata al navegador, al proveedor del autenticador y al backend como responsables separados del resultado.
El contrato práctico es sencillo: el usuario elige comenzar; el navegador y el autenticador realizan una ceremonia vinculada a la parte usuaria; el servidor valida la respuesta firmada y decide si crea una sesión; y el servicio ofrece alternativas accesibles y recuperación. Si cada capa tiene una responsabilidad clara, una passkey puede simplificar el acceso sin hacer afirmaciones de portabilidad, identidad, privacidad o recuperación que el sistema no pueda respaldar.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.