Guía para desarrolladores sobre las llaves de acceso para grupos 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, una parte de confianza (RP) controla 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 autentiquen con llaves de acceso) y un servidor para registrar, almacenar y verificar 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 del servidor de RP mediante el mecanismo de asociación que proporciona el SO, como los Vínculos de recursos digitales.
  • Autenticador: Es 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 llave de acceso nueva, debes proporcionar algunos componentes clave:

  • RP ID: 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: Incluye 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, de modo 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 nueva llave de acceso y se muestra una credencial de clave pública. Envíalo al servidor y almacena el ID de credencial y la clave pública para una autenticación futura.

Flujo de registro

Aprende a crear y registrar una llave de acceso en detalle:

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, debes proporcionar algunos componentes clave:

  • RP ID: 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 un RP 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íalo al servidor y verifica la firma con la clave pública almacenada.

Flujo de autenticación

Obtén información detallada sobre cómo 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 y mucho más. 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 llave de acceso por tu cuenta no es eficiente en el tiempo y puede causar errores que podrían conducir a 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 depasskeys.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)

Si admites llaves de acceso en tu servicio existente, la transición del mecanismo de autenticación más antiguo, 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 podría confundir a los usuarios o dejarlos atrás. Te recomendamos que conserves el método de autenticación existente por el momento.

Estos son algunos de los motivos:

  • Hay usuarios en un entorno incompatible con las llaves de acceso: La compatibilidad con llaves de acceso se está expandiendo ampliamente en varios sistemas operativos y navegadores, pero aquellos que usan versiones anteriores aún no pueden usar llaves de acceso.
  • El ecosistema de las llaves de acceso aún no ha madurado: 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 usar elementos nuevos. A medida que madura el ecosistema de llaves de acceso, obtendrán una idea de cómo funcionan y por qué son útiles para ellas.

Revisa tu mecanismo de autenticación existente

Si bien las llaves de acceso hacen que tu autenticación sea más simple y segura, conservar 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 para cada sitio web son tareas desafiantes para los usuarios. Se recomienda usar un administrador de contraseñas integrado en el sistema o uno independiente. Si haces un pequeño cambio en el formulario de acceso, los sitios web y las apps pueden marcar una gran diferencia en su experiencia de seguridad y acceso. Consulta cómo puedes realizar esos cambios:

Autenticación de dos factores

Si bien usar un administrador de contraseñas ayuda a los usuarios a controlar las contraseñas, no todos los usuarios las usan. Pedir 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, se reduce la probabilidad de usurpación de cuenta. Estos métodos no son tan sólidos como una llave de acceso, pero son mucho mejores que dejar a los usuarios solo con 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 al ingresar la OTP.

Federación de identidades

La federación de identidades es otra opción que permite 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 ideales 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 compilen. Para 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 observa si necesitas adoptar FedCM.

El acceso mediante 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á complicado. 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 las 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 con las llaves de acceso: