Las organizaciones y los desarrolladores se enfrentan a un obstáculo importante cuando trasladan a los usuarios de contraseñas a llaves de acceso. Si bien las llaves de acceso proporcionan una actualización de seguridad vital, el proceso de creación manual a menudo puede generar fricción. En un entorno de comercio electrónico de gran volumen, cada segundo de duda es importante, ya que cualquier demora puede interrumpir el proceso de compra y provocar el abandono del carrito. Además, es fundamental mantener sincronizados los estados de las credenciales entre el servidor y el dispositivo del usuario para evitar errores de acceso y frustración del usuario.
adidas se enfrentó a estos mismos desafíos. Su objetivo principal era eliminar la fricción del proceso de acceso y simplificar la experiencia en las plataformas y los dispositivos web y de aplicaciones. Si bien la seguridad sigue siendo una prioridad alta, el equipo de productos se enfocó en hacer que los flujos de acceso y registro con llaves de acceso sean lo más fluidos posible.
Para abordar estos desafíos, adidas implementó Conditional Create para actualizar automáticamente los usuarios de contraseñas a llaves de acceso y la API de Signal para mantener las credenciales coherentes. Además, implementaron Related Origin Requests para admitir el uso entre dominios cuando sea necesario.
Los resultados
La estrategia de adidas de automatizar la creación de llaves de acceso y mantener la integridad de las credenciales produjo resultados inmediatos y medibles tanto en la adopción como en la confiabilidad del acceso:
- Tasa de adopción alta: Desde el lanzamiento del proceso de acceso con llave de acceso, adidas logró una tasa general de creación de llaves de acceso del 47%. Esto incluye la creación condicional automatizada y las habilitaciones iniciadas por el usuario cuando se le solicita durante los flujos de acceso o registro. Esta adopción fue particularmente alta en dispositivos móviles, que tuvieron un porcentaje de conversiones del 52% (en comparación con el 34% en computadoras).
- Actualizaciones aceleradas con Conditional Create: Más allá de las indicaciones explícitas, Adidas logró un aumento del 8% en la creación de llaves de acceso gracias a la actualización sin problemas de los usuarios existentes de contraseñas en segundo plano, sin necesidad de que el usuario realice acciones manuales.
- Confiabilidad casi perfecta para acceder: Las llaves de acceso tuvieron una tasa de éxito superior al 99% una vez que se inició el acceso. Esta es una importante actualización de seguridad en comparación con el historial de la tasa de éxito de contraseñas de adidas del 70%, que a menudo se reducía por errores humanos, como errores tipográficos o credenciales olvidadas.
- Reducción de la fricción y los errores: Al implementar la API de Signal para sincronizar automáticamente las credenciales del dispositivo y del servidor, adidas logró mantener los errores de
PASSKEY_NOT_FOUNDen menos del 0.3% de los intentos de acceso. Esto eliminó de manera eficaz la frustración de los usuarios por las llaves de acceso huérfanas.
47 %
Tasa de creación de llaves de acceso
8 %
Aumento en la creación de llaves de acceso con Conditional Create
>99 %
Tasa de éxito del acceso con llave de acceso una vez que se inicia
<0.3 %
Tasa de errores de llaves de acceso huérfanas
Cómo resolvió adidas el problema
A continuación, se muestra cómo adidas abordó estos desafíos:
1. Acelera la adopción con Conditional Create
Para ayudar a los usuarios a adoptar las llaves de acceso sin problemas, adidas implementó la función Conditional Create. Esta función permite que un sitio web cree automáticamente una llave de acceso cuando un usuario accede con una contraseña almacenada en su administrador de contraseñas. Para garantizar la mayor tasa de éxito, el sistema llama a la API inmediatamente después de un acceso exitoso para que el sistema reconozca el uso de la contraseña como reciente.
const cred = await navigator.credentials.create({
publicKey: options,
mediation: 'conditional' // Enables automatic passkey creation
});
Adidas integró esta función con lógica personalizada que primero valida el entorno del usuario. Específicamente, el sistema verifica si el navegador admite la función Conditional Create. El sistema también respeta las preferencias del usuario, ya que suprime el mensaje si el usuario ya omitió la creación de la llave de acceso tres veces en los últimos seis meses.
Si el entorno es compatible, el sistema intentará crear la llave de acceso en segundo plano inmediatamente después de que se complete la autenticación del usuario. Este momento específico aumenta la probabilidad de que se cumplan los requisitos previos. Es importante destacar que la implementación controla las excepciones de WebAuthn con una filosofía de "apertura en caso de falla" para priorizar siempre el acceso del usuario. Si el navegador informa un InvalidStateError, lo que indica que es probable que ya exista una llave de acceso, el sistema detiene la creación en segundo plano y accede de inmediato a la cuenta del usuario. Por el contrario, si se produce un NotAllowedError, lo que significa que no se cumplieron las condiciones específicas para la creación automática, el sistema detecta este estado y guía al usuario a una pantalla de "Passkey Collector" para guiarlo a través de un proceso de configuración manual. Al distinguir entre estas limitaciones técnicas y los comportamientos de los usuarios, adidas se asegura de que el impulso para las actualizaciones de llaves de acceso mejore la experiencia de acceso en lugar de interrumpirla.
2. Garantiza la confiabilidad con la API de Signal
A medida que los usuarios administran sus credenciales en diferentes dispositivos, pueden surgir inconsistencias. Por ejemplo, es posible que se borre una llave de acceso del servidor, pero que permanezca en el dispositivo del usuario. Para evitar errores de acceso causados por estas credenciales "fantasma", adidas implementó la API de Signal. Esta API permite que el servidor señale el estado de las credenciales al proveedor de llaves de acceso.
adidas usa los tres métodos disponibles de la API de Signals para mantener esta coherencia. En lugar de adivinar qué credenciales quitar, adidas asigna eventos específicos del ciclo de vida del usuario a la llamada a la API correspondiente:
- Errores de registro: Cuando se crea una llave de acceso en el cliente, pero no se registra en el backend, adidas usa
signalUnknownCredentialpara quitar de inmediato la credencial huérfana. - Accesos no válidos: Si un usuario intenta acceder con una llave de acceso revocada o desactualizada,
signalUnknownCredentialle indica al proveedor que la oculte. - Administración de usuarios: Cuando un usuario quita explícitamente una llave de acceso en la configuración de su cuenta,
signalAllAcceptedCredentialssincroniza la lista de entidades permitidas. Esto garantiza que ya no se ofrezca la llave de acceso borrada. - Actualizaciones de la cuenta: Cuando un usuario cambia su correo electrónico o nombre de usuario,
signalCurrentUserDetailsactualiza los metadatos en el dispositivo para que coincidan con los del servidor.
// Detect authentication failure due to lack of the credential
if (result.status === 404) {
if (PublicKeyCredential.signalUnknownCredential) {
await PublicKeyCredential.signalUnknownCredential({
rpId: "adidas.com",
credentialId: "..." // base64url encoded credential ID
});
}
}
3. Unifica el acceso con solicitudes de origen relacionado y vínculos de recursos digitales
Para respaldar aún más su arquitectura de múltiples mercados, adidas implementó las solicitudes de origen relacionado. Si bien la mayoría de los usuarios se limitan a su mercado local (por ejemplo, adidas.nl), esta configuración permite que los usuarios que navegan entre regiones reutilicen las llaves de acceso en los dominios permitidos segmentando un solo ID de entidad de confianza (adidas.com).
Para habilitar esta opción, adidas aloja un archivo de configuración webauthn en su dominio principal del ID de grupo de confianza (RP ID). Este archivo contiene una lista de entidades permitidas explícita de orígenes que pueden usar adidas.com para el registro y la autenticación con llave de acceso. Al definir estas relaciones, el navegador puede verificar que una llave de acceso creada en un sitio regional sea válida para usarse en otro, lo que proporciona una experiencia sin problemas para los usuarios globales.
// https://www.adidas.com/.well-known/webauthn
{
"origins": [
"https://www.adidas.fi",
"https://www.adidas.nl",
// ... abridged (the full file lists 50+ regional domains)
]
}
Es importante destacar que adidas también proporcionó compatibilidad perfecta con llaves de acceso en sus apps para dispositivos móviles Android con Digital Asset Links. Dado que las apps usan una WebView alojada en idp.adidas.com para la autenticación, se requirieron vínculos de recursos digitales para establecer una relación de confianza entre la app para Android y el ID de la entidad externa (adidas.com). Esta verificación permite que la app acceda a las mismas llaves de acceso que se usan en la Web, lo que crea una experiencia de acceso fluida y unificada en todas las plataformas.
Para lograrlo, adidas aloja un archivo de Vínculos de recursos digitales (assetlinks.json) en sus respectivos dominios web. Este archivo declara públicamente la asociación criptográfica con sus aplicaciones para Android. Del mismo modo, para admitir su ecosistema de iOS, adidas usa dominios asociados.
Al alojar un archivo apple-app-site-association, establecen una conexión segura que permite que su app para iOS use llaves de acceso de forma segura en una vista web.
// https://www.adidas.fi/.well-known/assetlinks.json
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.adidas.app",
"sha256_cert_fingerprints": [
"B2:55:43:78:89:F6:F6:FD:BB:16:5C:43:EE:66:14:18:D4:E8:33:6D:3A:1F:68:86:C3:A8:7C:89:2B:51:45:96",
"..."
]
}
},
// ... abridged
]
¿Qué sigue para adidas?
Con una base sólida de actualizaciones automáticas y credenciales sincronizadas disponibles en adidas.fi y adidas.nl, adidas implementará esta configuración sin problemas en todos los demás mercados globales para fines de abril de 2026. Además, adidas está explorando experiencias de acceso aún más sencillas con la prueba del origen de mediación inmediata. En el futuro, planeamos permitir que los usuarios creen cuentas directamente con llaves de acceso. De esta manera, se quita el requisito actual de registrarse primero con un método alternativo. El equipo también está investigando el "activador inteligente" para invocar directamente el diálogo de la llave de acceso del sistema en el segundo paso del acceso. Esto elimina la necesidad de un clic adicional cuando hay una alta confianza en que el usuario tiene una llave de acceso disponible en su dispositivo actual.
Por qué es importante para ti
El cambio a la autenticación sin contraseña se realiza correctamente cuando la experiencia del usuario sigue siendo fluida. Si implementas Conditional Create, puedes migrar a los usuarios sin problemas y sin interrumpir sus hábitos. Con las solicitudes de origen relacionado, puedes compartir esas llaves de acceso en tus dominios, lo que permite que los usuarios accedan sin problemas a todo tu ecosistema con una sola llave de acceso. Por último, la vinculación con la API de Signal garantiza que tu experiencia unificada y sin contraseñas siga siendo confiable y sin errores.