Guía para desarrolladores sobre llaves de acceso para terceros de confianza

Obtén información para integrar llaves de acceso en tu servicio.

Anatomía de un sistema de llaves de acceso

Un sistema de llaves de acceso consta de algunos componentes:

  • Parte de confianza: En el contexto de las llaves de acceso, un usuario de confianza (RP) se encarga de la emisión y autenticación de las llaves de acceso. El RP debe operar un cliente (un sitio web o una app que cree llaves de acceso o se autentique con llaves de acceso) y un servidor para registrar, almacenar y verificar las credenciales generadas por las llaves de acceso del cliente. Una aplicación para dispositivos móviles con llave de acceso debe estar vinculada a un dominio de servidor de RP mediante el mecanismo de asociación proporcionado por el SO, como los Vínculos de recursos digitales.
  • Autenticador: Se trata de un dispositivo informático, como un teléfono celular, una tablet, una laptop o una computadora de escritorio, que puede crear y verificar llaves de acceso mediante la función de bloqueo de pantalla que ofrece el sistema operativo.
  • Administrador de contraseñas: Es el software instalado en los dispositivos del usuario final que entrega, almacena y sincroniza llaves de acceso, como el Administrador de contraseñas de Google.

Flujo de registro

Usa la API de WebAuthn en un sitio web o la biblioteca del Administrador de credenciales en una app para Android a fin de crear y registrar una llave de acceso nueva.

Para crear una nueva llave de acceso, debes proporcionar algunos componentes clave:

  • ID de RP: Proporciona el ID del usuario de confianza en forma de dominio web.
  • Información del usuario: El ID, el nombre de usuario y un nombre visible del usuario.
  • Credenciales para excluir: Información sobre las llaves de acceso almacenadas previamente para evitar el registro duplicado.
  • Tipos de llaves de acceso: Indica si se debe usar el dispositivo en sí ("autenticador de plataforma") como autenticador o una llave de seguridad extraíble ("autenticador multiplataforma o de roaming"). Además, los emisores pueden especificar si desean que la credencial sea detectable para que el usuario pueda seleccionar una cuenta con la que acceder.

Una vez que un RP solicita crear una llave de acceso y el usuario la verifica con un desbloqueo de pantalla, se crea una llave de acceso nueva y se muestra una credencial de clave pública. Envíala al servidor y almacena el ID de la credencial y la clave pública para una autenticación futura.

Flujo de registro

Obtén información detallada para crear y registrar una llave de acceso:

Flujo de autenticación

Usa la API de WebAuthn en un sitio web o la biblioteca del Administrador de credenciales en una app para Android a fin de autenticar con una llave de acceso registrada.

Para autenticar con una llave de acceso, hay algunos componentes clave que debes proporcionar:

  • ID de RP: Proporciona el ID del usuario de confianza en forma de dominio web.
  • Desafío: Es un desafío generado por el servidor que evita ataques de repetición.

Una vez que una parte restringida solicita una autenticación con una llave de acceso y el usuario la verifica con un desbloqueo de pantalla, se muestra una credencial de clave pública. Envíala al servidor y verifica la firma con la clave pública almacenada.

Flujo de autenticación

Obtén información detallada para autenticar con una llave de acceso:

Integraciones del servidor

Cuando se crea una llave de acceso, el servidor debe proporcionar parámetros clave, como un desafío, información del usuario, IDs de credenciales que se deben excluir, entre otros. Luego, verifica la credencial de clave pública creada que envió el cliente y la almacena en la base de datos. Para autenticarse con una llave de acceso, el servidor debe validar cuidadosamente la credencial y verificar la firma para permitir que el usuario acceda.

Sin embargo, compilar un servidor de llaves de acceso por tu cuenta no es eficiente en cuanto al tiempo y puede causar errores que podrían provocar un incidente de seguridad crítico. Te recomendamos que uses una de las bibliotecas de código abierto disponibles o una solución que pueda ayudarte a acelerar la integración de las llaves de acceso.

Para encontrar la lista de bibliotecas de código abierto, consulta la sección Bibliotecas de Passkeys.dev o una lista de bibliotecas de WebAuthn de código abierto. Para encontrar una solución, FIDO Alliance tiene una lista de servidores FIDO2 certificados.

Mecanismos de autenticación existentes (heredados)

Cuando admites llaves de acceso en tu servicio existente, la transición del mecanismo de autenticación anterior, como las contraseñas a las llaves de acceso, no ocurrirá en un día. Sabemos que podrías eliminar el método de autenticación más débil lo antes posible, pero eso puede confundir a los usuarios o dejarlos atrás. Te recomendamos que conserves el método de autenticación existente por el momento.

Existen varias razones:

  • Hay usuarios en un entorno incompatible con las llaves de acceso: La compatibilidad con llaves de acceso se está expandiendo ampliamente a varios sistemas operativos y navegadores, pero los que usan versiones anteriores aún no pueden usar las llaves de acceso.
  • El ecosistema de llaves de acceso aún no madura: El ecosistema de llaves de acceso está evolucionando. Los detalles de la UX y la compatibilidad técnica entre diferentes entornos pueden mejorar.
  • Es posible que los usuarios aún no estén listos para vivir con una llave de acceso: hay personas que dudan en probar cosas nuevas. A medida que el ecosistema de llaves de acceso avance, obtendrán una idea de su funcionamiento y de su utilidad.

Revisa tu mecanismo de autenticación existente

Si bien las llaves de acceso hacen que tu autenticación sea más simple y segura, mantener los mecanismos antiguos es como dejar un agujero. Te recomendamos revisar y mejorar tus mecanismos de autenticación existentes.

Contraseñas

Crear contraseñas seguras y administrarlas en cada sitio web son tareas desafiantes para los usuarios. Se recomienda usar un administrador de contraseñas integrado en el sistema o uno independiente. Los sitios web y las apps pueden marcar una gran diferencia en el formulario de acceso y en su seguridad. Consulta cómo puedes realizar esos cambios:

Autenticación de dos factores

Si bien el uso de un administrador de contraseñas ayuda a los usuarios a administrar las contraseñas, no todos los usuarios las usan. Solicitar una credencial adicional llamada contraseña de un solo uso (OTP) es una práctica común para proteger a esos usuarios. Por lo general, las OTP se proporcionan a través de un correo electrónico, un mensaje SMS o una app de autenticación como el Autenticador de Google. Debido a que las OTP suelen ser un texto corto que se genera de forma dinámica solo durante un período limitado, disminuye la probabilidad de usurpaciones de cuentas. Estos métodos no son tan sólidos como una llave de acceso, pero son mucho mejores que dejar a los usuarios con solo una contraseña.

Si seleccionas SMS como una forma de entregar una OTP, consulta las siguientes prácticas recomendadas para optimizar la experiencia del usuario para ingresar a la OTP.

Federación de identidades

La federación de identidades es otra opción para permitir que los usuarios accedan de forma fácil y segura. Con la federación de identidades, los sitios web y las apps pueden permitir que los usuarios accedan con su identidad desde un proveedor de identidad de terceros. Por ejemplo, Acceder con Google ofrece excelentes conversiones para los desarrolladores, y a los usuarios les resulta más fácil y preferible la autenticación basada en contraseñas. La federación de identidades es complementaria a las llaves de acceso. Es ideal para registrarse, ya que el sitio web o la app pueden obtener información básica de perfil del usuario en un solo paso, mientras que las llaves de acceso son excelentes para optimizar la reautenticación.

Ten en cuenta que, después de que Chrome elimine gradualmente las cookies de terceros en 2024, algunos sistemas de federación de identidades pueden verse afectados según cómo se hayan creado. A fin de mitigar el impacto, se está desarrollando una nueva API para navegadores llamada API de Federated Credential Management (FedCM). Si ejecutas un proveedor de identidad, consulta los detalles y verifica si necesitas adoptar FedCM.

El acceso con vínculo mágico es un método de autenticación en el que un servicio proporciona un vínculo de acceso a través de un correo electrónico para que el usuario pueda hacer clic en él y autenticarse. Si bien esto ayuda a los usuarios a acceder sin recordar una contraseña, cambiar entre el navegador o la app y el cliente de correo electrónico será una fricción. Además, como el mecanismo de autenticación se basa en el correo electrónico, la seguridad débil del proveedor de correo electrónico puede poner en riesgo las cuentas de los usuarios.

Recursos de aprendizaje

Web

Para integrar llaves de acceso en tu sitio web, usa la API de Web Authentication (WebAuthn). Para obtener más información, consulta los siguientes recursos:

Android

A fin de integrar las llaves de acceso en tu app para Android, usa la biblioteca del Administrador de credenciales. Para obtener más información, consulta los siguientes recursos:

UX

Conoce las recomendaciones para la experiencia del usuario relacionadas con las llaves de acceso: