Organizações e desenvolvedores enfrentam um obstáculo significativo ao migrar usuários de senhas para chaves de acesso. Embora as chaves de acesso ofereçam uma atualização de segurança vital, o processo de criação manual pode gerar atrito. Em um ambiente de e-commerce de alto volume, cada segundo de hesitação é importante, porque qualquer atraso pode interromper o caminho para a compra e levar ao abandono do carrinho. Além disso, manter os estados de credenciais sincronizados entre o servidor e o dispositivo do usuário é essencial para evitar erros de login e frustração do usuário.
A adidas enfrentou exatamente esses desafios. O principal objetivo era remover a fricção do processo de login e simplificar a experiência em plataformas e dispositivos da Web e de apps. Embora a segurança continue sendo uma alta prioridade, a equipe de produtos se concentrou em tornar os fluxos de inscrição e login o mais simples possível com as chaves de acesso.
Para resolver esses desafios, a adidas implementou a criação condicional para fazer upgrade automático dos usuários de senha para chaves de acesso e a API Signal para manter as credenciais consistentes. Além disso, eles implantaram Solicitações de origem relacionada para oferecer suporte ao uso entre domínios quando necessário.
Os resultados
A estratégia da adidas de automatizar a criação de chaves de acesso e manter a integridade das credenciais gerou resultados imediatos e mensuráveis tanto na adoção quanto na confiabilidade do login:
- Alta taxa de adoção:desde o lançamento do processo de login com chaves de acesso, a adidas atingiu uma taxa geral de criação de chaves de acesso de 47%. Isso inclui a criação condicional automatizada e as ativações iniciadas pelo usuário quando solicitado durante os fluxos de inscrição ou login. Essa adoção foi particularmente alta em dispositivos móveis, que tiveram uma taxa de conversão de 52% (em comparação com 34% em computadores).
- Upgrades acelerados usando a criação condicional:além dos comandos explícitos, a adidas alcançou um aumento de 8% na criação de chaves de acesso ao fazer upgrade dos usuários de senha atuais em segundo plano, sem exigir ação manual do usuário.
- Confiabilidade de login quase perfeita:as chaves de acesso tiveram uma taxa de sucesso superior a 99% depois que um login foi iniciado. Essa é uma grande melhoria de segurança em comparação com a taxa de sucesso histórica de senhas da adidas, que era de 70% e muitas vezes era reduzida por erros humanos, como erros de digitação ou credenciais esquecidas.
- Redução de atritos e erros:ao implantar a API Signal para sincronizar automaticamente as credenciais do dispositivo e do servidor, a adidas conseguiu manter os erros de
PASSKEY_NOT_FOUNDem menos de 0,3% das tentativas de login. Isso eliminou a frustração do usuário com chaves de acesso órfãs.
47 %
Taxa de criação de chaves de acesso
8 %
Aumento nas criações de chaves de acesso usando a criação condicional
>99 %
Taxa de sucesso do login com chave de acesso após o início
<0,3 %
Taxa de erros de chaves de acesso órfãs
Como a adidas resolveu o problema
Veja como a adidas enfrentou esses desafios:
1. Acelere a adoção com a criação condicional
Para ajudar os usuários a adotar as chaves de acesso sem problemas, a adidas implementou a criação condicional. Esse recurso permite que um site crie automaticamente uma chave de acesso quando um usuário faz login com uma senha armazenada no gerenciador de senhas. Para garantir a maior taxa de sucesso, o sistema chama a API imediatamente após um login bem-sucedido para que o uso da senha seja reconhecido como recente.
const cred = await navigator.credentials.create({
publicKey: options,
mediation: 'conditional' // Enables automatic passkey creation
});
A adidas integrou esse recurso com uma lógica personalizada que primeiro valida o ambiente do usuário. Especificamente, o sistema verifica se o recurso de criação condicional tem suporte no navegador. O sistema também respeita as preferências do usuário ao suprimir a solicitação se ele já tiver pulado a criação de chaves de acesso três vezes nos últimos seis meses.
Se o ambiente for compatível, o sistema vai tentar criar a chave de acesso em
segundo plano, imediatamente após a autenticação bem-sucedida do usuário. Esse momento específico aumenta a probabilidade de os pré-requisitos serem atendidos. É importante ressaltar que a implementação processa exceções do WebAuthn com uma filosofia de "abertura em caso de falha" para sempre priorizar o acesso do usuário. Se o navegador informar um InvalidStateError,
indicando que provavelmente já existe uma chave de acesso, o sistema interrompe a
criação em segundo plano e faz login do usuário imediatamente. Por outro lado, se ocorrer um NotAllowedError, o que significa que as condições específicas para a criação automática não foram atendidas, o sistema vai detectar esse estado e direcionar o usuário para uma tela do Coletor de chaves de acesso para orientá-lo em um processo de configuração manual. Ao distinguir entre essas restrições técnicas e comportamentos do usuário, a adidas garante que a iniciativa de upgrades de chaves de acesso melhore a experiência de login em vez de interrompê-la.
2. Garantir a confiabilidade com a API Signal
À medida que os usuários gerenciam as credenciais em vários dispositivos, podem surgir inconsistências. Por exemplo, uma chave de acesso pode ser excluída do servidor, mas permanecer no dispositivo do usuário. Para evitar falhas de login causadas por essas credenciais "fantasma", a adidas implementou a API Signal. Essa API permite que o servidor sinalize o status das credenciais para o provedor de chaves de acesso.
A adidas usa todos os três métodos disponíveis da API Signal para manter essa consistência. Em vez de adivinhar quais credenciais remover, a adidas mapeia eventos específicos do ciclo de vida do usuário para a chamada de API adequada:
- Falhas de registro:quando uma chave de acesso é criada no cliente, mas não é
registrada no back-end, a adidas usa o
signalUnknownCredentialpara remover imediatamente a credencial órfã. - Logins inválidos:se um usuário tentar fazer login com uma chave de acesso revogada ou desatualizada, o
signalUnknownCredentialvai sinalizar o provedor para ocultá-la. - Gerenciamento de usuários:quando um usuário remove explicitamente uma chave de acesso nas configurações da conta, o
signalAllAcceptedCredentialssincroniza a lista de permissões. Isso garante que a chave de acesso excluída não seja mais oferecida. - Atualizações da conta:quando um usuário muda o e-mail ou o nome de usuário, o
signalCurrentUserDetailsatualiza os metadados no dispositivo para corresponder ao 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. Unificar o acesso com solicitações de origem relacionadas e Digital Asset Links
Para dar suporte à arquitetura multimercado, a adidas implementou Solicitações de origem relacionadas. Embora a maioria dos usuários
permaneça no mercado local (por exemplo, adidas.nl), essa
configuração permite que os usuários que navegam entre regiões reutilizem chaves de acesso em
domínios permitidos segmentando um único ID de
parte confiável (adidas.com).
Para ativar isso, a adidas hospeda um arquivo de configuração webauthn no domínio principal
ID da parte confiável (RP ID). Esse arquivo contém uma lista de permissão explícita de
origens que podem usar adidas.com para registro e
autenticação de chaves de acesso. Ao definir essas relações, o navegador pode verificar se uma
chave de acesso criada em um site regional é válida para uso em outro, proporcionando uma
experiência sem atrito para usuários globais.
// https://www.adidas.com/.well-known/webauthn
{
"origins": [
"https://www.adidas.fi",
"https://www.adidas.nl",
// ... abridged (the full file lists 50+ regional domains)
]
}
Além disso, a adidas ofereceu suporte perfeito para chaves de acesso nos apps para dispositivos móveis Android usando os Digital Asset Links. Como os apps usam uma WebView hospedada em idp.adidas.com para autenticação, os Digital Asset Links foram necessários para estabelecer uma relação de confiança entre o app Android e o ID da parte confiável (adidas.com). Essa verificação permite que o app acesse as mesmas chaves de acesso usadas na Web, criando uma experiência de login unificada e tranquila em todas as plataformas.
Para isso, a adidas hospeda um arquivo Digital Asset Links (assetlinks.json) nos respectivos domínios da Web. Esse arquivo declara publicamente a associação criptográfica com os aplicativos Android. Da mesma forma, para oferecer suporte ao ecossistema iOS, a adidas usa Domínios associados.
Ao hospedar um arquivo apple-app-site-association, eles estabelecem uma conexão segura que permite que o app iOS use chaves de acesso em uma visualização da Web com segurança.
// 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
]
O que vem por aí para a adidas?
Com uma base sólida de upgrades automáticos e credenciais sincronizadas ativas em adidas.fi e adidas.nl, a adidas vai implantar essa configuração integrada em todos os outros mercados globais até o fim de abril de 2026. Além disso, a adidas está testando a origem de mediação imediata de teste para oferecer experiências de login ainda mais simples. Os planos futuros incluem permitir que os usuários criem contas diretamente com chaves de acesso. Isso remove a exigência atual de se inscrever primeiro com um método alternativo. A equipe também está investigando o "acionamento inteligente" para invocar diretamente a caixa de diálogo da chave de acesso do sistema na segunda etapa do login. Isso elimina a necessidade de um clique extra quando há alta confiança de que o usuário tem uma chave de acesso disponível no dispositivo atual.
Por que isso é importante para você
A mudança para a autenticação sem senha é bem-sucedida quando a experiência do usuário permanece integrada. Ao implementar a criação condicional, você pode migrar usuários das senhas sem interromper os hábitos deles. Ao usar Related Origin Requests, você pode compartilhar essas chaves de acesso entre seus domínios, permitindo que os usuários acessem todo o ecossistema com uma única chave de acesso. Por fim, a combinação com a API Signal garante que sua experiência unificada e sem senha permaneça confiável e sem erros.