Testando gerenciadores de senhas para Passkeys de aplicativos nativos

Com o lançamento do iOS 17 e do Android 14, o cenário de passkeys para aplicativos móveis nativos mudou fundamentalmente. Pela primeira vez, gerenciadores de senhas de terceiros podem atuar como provedores de passkeys, quebrando o domínio exclusivo do iCloud Keychain e do Google Password Manager. Isso permite que os usuários usem suas soluções de confiança, como 1Password, Bitwarden ou Dashlane, nos fluxos de autenticação de aplicativos nativos. Embora seja uma grande vitória para a escolha do usuário, isso introduz uma complexidade significativa para os desenvolvedores. Sua implementação de passkeys pode se comportar de maneira diferente entre gerenciadores de senhas distintos em aplicativos móveis nativos. Por isso, é importante que qualquer equipe teste adequadamente passkeys de aplicativos nativos e gerenciadores de senhas de terceiros.

Este guia abrangente compartilha nossa abordagem testada e comprovada para testar passkeys em aplicativos nativos com gerenciadores de senhas de terceiros. Embora o ecossistema de passkeys tenha amadurecido significativamente em 2025, a implementação no mundo real ainda exige uma validação cuidadosa entre diversas implementações de gerenciadores de senhas. Nós compilamos nossa experiência em um plano de teste prático que garante que seu aplicativo nativo funcione perfeitamente com os gerenciadores de senhas preferidos dos usuários.

O ecossistema de gerenciadores de senhas evoluiu para além das soluções nativas das plataformas. Os usuários escolhem ativamente gerenciadores de senhas de terceiros, como 1Password, Bitwarden, Dashlane, Proton Pass e NordPass, com base em suas necessidades específicas, como sincronização entre plataformas, recursos empresariais ou preferências de privacidade. Seu aplicativo nativo de iOS / Android deve acomodar essa diversidade sem forçar os usuários a trocarem sua solução de gerenciamento de senhas de confiança.

Com base nos dados que medimos nas páginas da Corbado, vemos que apenas 5-10% dos usuários em geral dependem de gerenciadores de senhas de terceiros. Embora esse número possa parecer baixo, ele terá um grande impacto na percepção da sua implementação de passkeys e no número de tickets de suporte se você estiver trabalhando em um ambiente de grande escala. Vimos que alguns gerenciadores de senhas implementam a especificação WebAuthn de maneira ligeiramente diferente, levando a variações sutis na experiência do usuário ou até mesmo a bugs.

Os aplicativos nativos de iOS e Android oferecem maneiras diferentes de usar passkeys. No Android, você encontrará sobreposições (overlays) de passkeys e campos de texto manuais que acionam a cerimônia de passkey (para aplicativos web, o Android também suporta a Conditional UI). O iOS apresenta seu próprio conjunto de sobreposições de passkeys, além da Conditional UI e também de campos de texto manuais. Além disso, existem outros casos extremos a serem verificados. No geral, sua aplicação nativa deve lidar de forma elegante com:

• Logins com sobreposição de passkey que aparecem imediatamente no carregamento da página
• Logins com Conditional UI (apenas iOS) que sugerem automaticamente as passkeys disponíveis
• Logins em campos de texto onde o usuário informa seu nome de usuário antes de clicar em um botão
• Autenticação entre dispositivos (Cross-device authentication - CDA) para uso de passkey com outro dispositivo
• Mecanismos de fallback quando o uso de passkeys não está disponível

A configuração correta das flags determina se as passkeys funcionarão como esperado entre dispositivos e plataformas. Os valores críticos incluem:

• Relying Party ID (rpID): Deve corresponder exatamente entre as implementações web e nativa e é o domínio ao qual a passkey está vinculada
• Verificação do usuário: Determina que o usuário precisa fornecer sua autenticação local
• Chave residente/credenciais detectáveis: Permite a autenticação sem nome de usuário (possibilita a Conditional UI)
• Elegibilidade de backup (BE) e estado de backup (BS): Permitem a sincronização de passkeys entre dispositivos

Flags mal configuradas nem sempre causam falhas imediatas. No entanto, elas podem criar problemas sutis e inconsistências, como passkeys estarem disponíveis em um dispositivo, mas não sincronizadas entre outros (mesmo que o mesmo gerenciador de senhas de terceiros esteja disponível em ambos os dispositivos). Uma de nossas descobertas nos testes foi que alguns gerenciadores de senhas de terceiros definem as flags BE/BS incorretamente, sendo responsáveis por uma grande parte dos problemas com passkeys.

Arquiteturas de atividade única (Android) e cena única (iOS) exigem um gerenciamento meticuloso do ciclo de vida. Quando uma tela de gerenciador de senhas aparece e é dispensada, seu aplicativo deve preservar o estado, lidar com callbacks e retomar corretamente. Isso é especialmente crítico no Android, onde a configuração launchMode pode causar comportamento inesperado.

Por exemplo, descobrimos que definir a MainActivity como launchMode="singleInstance" criava problemas. Em algumas versões do Android e personalizações de fabricantes (OEMs), esse modo faz com que a UI do Gerenciador de Credenciais de Passkey seja aberta como uma tarefa separada. Isso não apenas adiciona uma entrada de aplicativo confusa e adicional à tela de "Recentes", mas também pode fazer com que o aplicativo trave se for colocado em segundo plano enquanto a caixa de diálogo da passkey estiver aberta.

A correção recomendada é alterar a configuração para launchMode="singleTask". Isso impede que o Gerenciador de Credenciais crie uma tarefa separada, garantindo um ciclo de vida mais previsível entre diferentes OEMs (Samsung, Google, Vivo, etc.) e reduzindo o risco de bugs específicos de cada fornecedor. Isso proporciona uma base mais estável para testar navegação, sobreposições e deeplinks.

Observamos que esses problemas de ciclo de vida muitas vezes se disfarçam de "bugs do gerenciador de senhas", quando na verdade são problemas no nível da aplicação. Uma instrumentação e testes adequados entre diferentes provedores ajudam a identificar esses padrões precocemente.

Concentre seus testes de passkeys em aplicativos nativos nos gerenciadores de senhas de terceiros mais amplamente adotados:

Alvos primários (cobertura essencial):

• 1Password
• Bitwarden
• Dashlane
• Proton Pass
• NordPass

Alvos secundários (com base na sua base de usuários):

• Provedores regionais (por exemplo, Samsung Pass para dispositivos Samsung)
• Soluções empresariais, se o público for corporativo
• Padrões da plataforma (Google Password Manager, iCloud Keychain) como linha de base

Evite a tentação de testar todos os gerenciadores de senhas disponíveis. Concentre-se nos provedores que representam 90% da sua base de usuários. Nossas análises mostraram que os cinco alvos primários cobriram 85% dos usuários de gerenciadores de senhas de terceiros na UE/EUA/Reino Unido/AUS/NZ.

Antes de iniciar cada rodada de testes, garanta um ambiente limpo e reproduzível:

1. Limpe o estado das credenciais:

• Remova todas as credenciais existentes para o seu RP ID
• Limpe os caches do navegador e do aplicativo
• Faça logout completo e login novamente no gerenciador de senhas
• Force o fechamento e reabra o aplicativo alvo

2. Estabilize o ambiente de teste:

• Garanta conectividade de rede estável (sem VPNs durante os testes)
• Desative animações da UI se estiver automatizando os testes
• Use uma orientação de dispositivo consistente
• Documente a versão do sistema operacional, a versão do aplicativo e a versão do gerenciador de senhas

Cada teste valida aspectos específicos da funcionalidade da passkey. Documente os resultados sistematicamente usando um status de aprovado/reprovado e notas detalhadas para quaisquer anomalias.

Validar o tratamento correto do cancelamento

✓ A tela do gerenciador de senhas abre corretamente ✓ O usuário cancela sem criar uma passkey ✓ O aplicativo retorna para a tela de login ✓ Nenhuma credencial órfã no gerenciador de senhas ✓ A UI exibe opções de nova tentativa apropriadas

Verificar a criação de passkey após o fluxo de autenticação

✓ A autenticação local é iniciada de forma confiável ✓ A autenticação biométrica é concluída com sucesso ✓ A credencial é criada com o RP ID correto ✓ O aplicativo transita para o estado autenticado sem loops

Testar cenários de autenticação padrão

✓ A UI de sobreposição de passkey aparece ou o usuário fornece o nome de usuário no cenário de campo de texto ✓ A leitura biométrica e um único prompt biométrico levam a uma autenticação bem-sucedida ✓ Sem loops de seleção ou reaparecimento da tela ✓ A sessão permanece estável após a autenticação

Validar o gerenciamento de passkeys dentro do aplicativo

✓ RP ID, detectabilidade e flags BE/BS corretos ✓ O aplicativo permanece autenticado após a criação ✓ O gerenciador de senhas é atualizado imediatamente com os rótulos corretos

Testar o gerenciamento do ciclo de vida das credenciais

✓ Excluir passkey nas configurações ✓ O login com passkey não é possível ✓ Uma opção de fallback adequada é oferecida

Validar a portabilidade do aplicativo para a web

✓ O navegador reconhece as passkeys criadas no aplicativo ✓ A tela de seleção mostra a associação de RP correta ✓ A autenticação é concluída sem desvio por QR/CDA

Testar o compartilhamento de credenciais da web para o aplicativo

✓ O aplicativo exibe a credencial criada na web na seleção ✓ A autenticação na primeira tentativa é bem-sucedida ✓ Sem fallback forçado para senha

Verificar a sincronização de passkeys do aplicativo nativo para o navegador de desktop

✓ A passkey criada no aplicativo é sincronizada com o gerenciador de senhas do desktop ✓ A passkey sincronizada funciona perfeitamente no navegador do desktop ✓ Nenhum fluxo de código QR / entre dispositivos é acionado ✓ A autenticação é concluída sem loops ou erros

Verificar a sincronização de passkeys do navegador de desktop para o aplicativo nativo

✓ A passkey criada no desktop é sincronizada com o gerenciador de senhas móvel ✓ O aplicativo nativo exibe corretamente a passkey sincronizada ✓ A autenticação é bem-sucedida sem fallback para senha ✓ Os logs associam a asserção ao ID da credencial correto

Validar cenários de telefone como chave de segurança

✓ O telefone oferece a credencial criada no aplicativo para CDA na web ✓ Sem falsos erros de "nenhuma passkey disponível" ✓ A sessão da web é concluída após a biometria móvel

Nossos testes extensivos revelaram vários padrões recorrentes que afetam a integração de passkeys com gerenciadores de senhas de terceiros:

Problema: Credenciais criadas em um dispositivo podem não aparecer imediatamente em outros.

Solução: Implemente uma lógica de nova tentativa com backoff exponencial. Forneça opções de atualização manual para usuários que enfrentam atrasos na sincronização.

Problema: O comportamento do gerenciador de senhas varia significativamente entre as versões do sistema operacional, especialmente no Android 14+ e iOS 17+.

Solução: Mantenha uma matriz de compatibilidade e ajuste os fluxos com base na versão do sistema operacional detectada. Considere requisitos de versão mínima para uma experiência ideal.

Implementar com sucesso o suporte a passkeys de gerenciadores de senhas de terceiros em aplicativos nativos requer testes metódicos e atenção aos detalhes. Nosso plano de teste abrangente, refinado através de testes no mundo real, fornece uma base sólida para validar sua integração de passkeys.

Principais conclusões para a implantação em produção:

1. Teste sistematicamente: Use nosso plano de teste como base, adaptando-o aos seus casos de uso específicos
2. Respeite a escolha do usuário: Dê suporte aos gerenciadores de senhas que seus usuários preferem, não apenas aos padrões da plataforma
3. Monitore continuamente: Implemente um registro abrangente para capturar casos extremos em produção
4. Documente detalhadamente: Mantenha registros claros de comportamentos e soluções específicas de cada provedor

O ecossistema de passkeys continua a evoluir rapidamente. Os gerenciadores de senhas atualizam regularmente suas implementações, os sistemas operacionais introduzem novos recursos e a própria especificação WebAuthn avança. Ao estabelecer uma estrutura de testes robusta agora, você estará preparado para se adaptar à medida que a tecnologia amadurece.

Continuaremos atualizando nossos SDKs e metodologia de testes à medida que novos padrões surgirem. O investimento em testes abrangentes de gerenciadores de senhas de terceiros compensa com a redução da carga de suporte e a melhoria da satisfação do usuário. Afinal, a autenticação simplesmente deve funcionar - independentemente do gerenciador de senhas que seus usuários escolham.