Estudos de caso
O Zoho consegue logins seis vezes mais rápidos com a integração da chave de acesso e do Credential Manager
Leitura de 10 minutos
Como desenvolvedor Android, você está sempre procurando maneiras de melhorar a segurança, a experiência do usuário e simplificar o desenvolvimento. A Zoho, um pacote de software abrangente baseado na nuvem e focado em segurança e experiências integradas, alcançou melhorias significativas ao adotar chaves de acesso no app Android OneAuth.
Desde a integração das chaves de acesso em 2024, a Zoho alcançou velocidades de login até seis vezes mais rápidas do que os métodos anteriores e um crescimento de 31% mês a mês (MoM) na adoção de chaves de acesso.
Este estudo de caso examina a adoção de chaves de acesso e da API Credential Manager do Android pela Zoho para resolver dificuldades de autenticação. Ele detalha o processo de implementação técnica e destaca os resultados impactantes.
Como superar desafios de autenticação
O Zoho usa uma combinação de métodos de autenticação para proteger as contas de usuário. Isso incluiu o OneAuth da Zoho, a solução de autenticação multifator (MFA) da empresa, que oferecia suporte à autenticação com e sem senha usando notificações push, QR codes e senhas únicas baseadas em tempo (TOTP). O Zoho também aceitava logins federados, permitindo a autenticação pela Linguagem de marcação para autorização de segurança (SAML) e outros provedores de identidade de terceiros.
Desafios
Assim como muitas organizações, a Zoho queria melhorar a segurança da autenticação e a experiência do usuário, além de reduzir as cargas operacionais. Os principais desafios que levaram à adoção das chaves de acesso incluem:
- Vulnerabilidades de segurança: os métodos tradicionais baseados em senhas deixavam os usuários suscetíveis a ataques de phishing e vazamentos de senhas.
- Fricção do usuário: a fadiga de senhas levou a senhas esquecidas, frustração e maior dependência de processos de recuperação complicados.
- Ineficiências operacionais: o tratamento de redefinições de senha e problemas de MFA gerou um overhead de suporte significativo.
- Problemas de escalonabilidade: uma base de usuários crescente exigia uma solução de autenticação mais segura e eficiente.
Por que a mudança para chaves de acesso?
As chaves de acesso foram implementadas nos apps do Zoho para resolver desafios de autenticação, oferecendo uma abordagem sem senha que melhora significativamente a segurança e a experiência do usuário. Essa solução usa autenticação resistente a phishing, credenciais sincronizadas na nuvem para acesso fácil entre dispositivos e biometria (como impressão digital ou reconhecimento facial), PIN ou padrão para logins seguros, reduzindo as vulnerabilidades e inconvenientes associados às senhas tradicionais.
Ao adotar as chaves de acesso com o Credential Manager, o Zoho reduziu os tempos de login em até 6 vezes, diminuiu os custos de suporte relacionados a senhas e teve uma forte adoção pelos usuários, dobrando os logins com chave de acesso em quatro meses com um crescimento de 31% mês a mês. Agora, os usuários do Zoho aproveitam logins mais rápidos e fáceis e segurança resistente a phishing.
Implementação com o Credential Manager no Android
Então, como a Zoho conseguiu esses resultados? Eles usaram a API Credential Manager do Android, a biblioteca Jetpack recomendada para implementar a autenticação no Android.
O Credential Manager oferece uma API unificada que simplifica o processamento dos vários métodos de autenticação. Em vez de usar diferentes APIs para senhas, chaves de acesso e logins federados (como o Fazer login com o Google), você usa uma única interface.
A implementação de chaves de acesso no Zoho exigiu ajustes do lado do cliente e do lado do servidor. Confira um detalhamento detalhado do processo de criação, login e implementação do lado do servidor de chaves de acesso.
Criação de chave de acesso
Para criar uma chave de acesso, o app primeiro recupera detalhes de configuração do servidor da Zoho. Esse processo inclui uma verificação exclusiva, como impressão digital ou reconhecimento facial. Esses dados de confirmação de identidade, formatados como uma string requestJson, são usados pelo app para criar um CreatePublicKeyCredentialRequest. Em seguida, o app chama o método credentialManager.createCredential, que pede ao usuário para se autenticar usando o bloqueio de tela do dispositivo (biometria, impressão digital, PIN etc.).
Após a confirmação do usuário, o app recebe os novos dados de credencial da chave de acesso, envia de volta ao servidor da Zoho para verificação, e o servidor armazena as informações da chave de acesso vinculadas à conta do usuário. Falhas ou cancelamentos do usuário durante o processo são detectados e processados pelo app.
Login
O app Android do Zoho inicia o processo de login com chaves de acesso solicitando opções de login, incluindo um challenge exclusivo, do servidor de back-end do Zoho. Em seguida, o app usa esses dados para construir um GetCredentialRequest, indicando que ele vai se autenticar com uma chave de acesso. Em seguida, ele invoca a API CredentialManager.getCredential() do Android com essa solicitação. Essa ação aciona uma interface padronizada do sistema Android, pedindo que o usuário escolha a conta do Zoho (se houver várias chaves de acesso) e faça a autenticação usando o bloqueio de tela configurado no dispositivo (impressão digital, reconhecimento facial ou PIN). Após a autenticação, o Gerenciador de credenciais retorna uma declaração assinada (prova de login) ao app Zoho. O app encaminha essa declaração ao servidor do Zoho, que verifica a assinatura com a chave pública armazenada do usuário e valida o desafio, concluindo o processo de login seguro.
Implementação do lado do servidor
A transição da Zoho para oferecer suporte a chaves de acesso se beneficiou do fato de que os sistemas de back-end já estavam em conformidade com a FIDO WebAuthn, o que simplificou o processo de implementação do lado do servidor. No entanto, ainda eram necessárias modificações específicas para integrar totalmente a funcionalidade de chaves de acesso.
O desafio mais significativo envolveu a adaptação do sistema de armazenamento de credenciais. Os métodos de autenticação atuais do Zoho, que usam principalmente senhas e chaves de segurança FIDO para autenticação multifator, exigem abordagens de armazenamento diferentes das chaves de acesso, que são baseadas em chaves públicas criptográficas. Para resolver isso, o Zoho implementou um novo esquema de banco de dados projetado especificamente para armazenar com segurança chaves públicas de chaves de acesso e dados relacionados de acordo com os protocolos WebAuthn. Esse novo sistema foi criado com um mecanismo de pesquisa para validar e recuperar credenciais com base nas informações do usuário e do dispositivo, garantindo a compatibilidade com versões anteriores de métodos de autenticação mais antigos.
Outro ajuste do lado do servidor envolveu a implementação da capacidade de processar solicitações de dispositivos Android. As solicitações de chaves de acesso originadas de apps Android usam um formato de origem exclusivo (android:apk-key-hash:example) diferente das origens da Web padrão que usam um formato baseado em URI (https://example.com/app). A lógica do servidor precisou ser atualizada para analisar corretamente esse formato, extrair o hash de impressão digital SHA-256 do certificado de assinatura do app e validar em relação a uma lista pré-registrada. Essa etapa de verificação garante que as solicitações de autenticação realmente se originam do app Android da Zoho e protege contra ataques de phishing.
Este snippet de código demonstra como o servidor verifica o formato de origem específico do Android e valida o hash do certificado:
val origin: String = clientData.getString("origin")
if (origin.startsWith("android:apk-key-hash:")) {
val originSplit: List<String> = origin.split(":")
if (originSplit.size > 3) {
val androidOriginHashDecoded: ByteArray = Base64.getDecoder().decode(originSplit[3])
if (!androidOriginHashDecoded.contentEquals(oneAuthSha256FingerPrint)) {
throw IAMException(IAMErrorCode.WEBAUTH003)
}
} else {
// Optional: Handle the case where the origin string is malformed }
}
Tratamento de erros
A Zoho implementou mecanismos robustos de tratamento de erros para gerenciar erros do usuário e do desenvolvedor. Um erro comum, CreateCredentialCancellationException, apareceu quando os usuários cancelaram manualmente a configuração da chave de acesso. A Zoho rastreou a frequência desse erro para avaliar possíveis melhorias na experiência do usuário. Com base nas recomendações de UX do Android, a Zoho tomou medidas para educar melhor os usuários sobre as chaves de acesso, garantir que eles soubessem da disponibilidade delas e promover a adoção durante as tentativas de login subsequentes.
Este exemplo de código demonstra a abordagem da Zoho para lidar com os erros mais comuns de criação de chaves de acesso:
private fun handleFailure(e: CreateCredentialException) {
val msg = when (e) {
is CreateCredentialCancellationException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_CANCELLED", GROUP_NAME)
Analytics.addNonFatalException(e)
"The operation was canceled by the user."
}
is CreateCredentialInterruptedException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_INTERRUPTED", GROUP_NAME)
Analytics.addNonFatalException(e)
"Passkey setup was interrupted. Please try again."
}
is CreateCredentialProviderConfigurationException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_PROVIDER_MISCONFIGURED", GROUP_NAME)
Analytics.addNonFatalException(e)
"Credential provider misconfigured. Contact support."
}
is CreateCredentialUnknownException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_UNKNOWN_ERROR", GROUP_NAME)
Analytics.addNonFatalException(e)
"An unknown error occurred during Passkey setup."
}
is CreatePublicKeyCredentialDomException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_WEB_AUTHN_ERROR", GROUP_NAME)
Analytics.addNonFatalException(e)
"Passkey creation failed: ${e.domError}"
}
else -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_FAILED", GROUP_NAME)
Analytics.addNonFatalException(e)
"An unexpected error occurred. Please try again."
}
}
}
Testar chaves de acesso em ambientes de intranet
A Zoho enfrentou um desafio inicial ao testar chaves de acesso em um ambiente de intranet fechado. O processo de verificação do Gerenciador de senhas do Google para chaves de acesso exige acesso ao domínio público para validar o domínio da parte confiável (RP, na sigla em inglês). No entanto, o ambiente de teste interno da Zoho não tinha esse acesso à Internet pública, o que causou falha no processo de verificação e dificultou o teste bem-sucedido da autenticação por chaves de acesso. Para resolver isso, a Zoho criou um ambiente de teste de acesso público, que incluía a hospedagem de um servidor temporário com um arquivo de link de recurso e validação de domínio.
Este exemplo do arquivo assetlinks.json usado no ambiente de teste público do Zoho demonstra como associar o domínio da parte confiável ao app Android especificado para validação de chaves de acesso.
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.zoho.accounts.oneauth",
"sha256_cert_fingerprints": [
"SHA_HEX_VALUE"
]
}
}
]
Integrar com um servidor FIDO atual
O sistema de chaves de acesso do Android usa o padrão moderno FIDO2 WebAuthn. Esse padrão exige solicitações em um formato JSON específico, o que ajuda a manter a consistência entre aplicativos nativos e plataformas da Web. Para ativar o suporte a chaves de acesso do Android, a Zoho fez pequenas mudanças estruturais e de compatibilidade para gerar e processar corretamente solicitações que seguem a estrutura JSON FIDO2 necessária.
Essa atualização do servidor envolveu vários ajustes técnicos específicos:
1. Conversão de codificação:o servidor converte a codificação de URL Base64 (usada com frequência na WebAuthn para campos como IDs de credenciais) em codificação Base64 padrão antes de armazenar os dados relevantes. O snippet abaixo mostra como um rawId pode ser codificado em Base64 padrão:
// Convert rawId bytes to a standard Base64 encoded string for storage val base64RawId: String = Base64.getEncoder().encodeToString(rawId.toByteArray())
2. Formato da lista de transporte:para garantir o processamento consistente de dados, a lógica do servidor processa listas de mecanismos de transporte (como USB, NFC e Bluetooth, que especificam como o autenticador se comunicou) como matrizes JSON.
3. Alinhamento de dados do cliente:a equipe do Zoho ajustou como o servidor codifica e decodifica o campo clientDataJson. Isso garante que a estrutura de dados esteja alinhada precisamente com as expectativas das APIs internas atuais da Zoho. O exemplo abaixo ilustra parte da lógica de conversão aplicada aos dados do cliente antes que o servidor os processe:
private fun convertForServer(type: String): String {
val clientDataBytes = BaseEncoding.base64().decode(type)
val clientDataJson = JSONObject(String(clientDataBytes, StandardCharsets.UTF_8))
val clientJson = JSONObject()
val challengeFromJson = clientDataJson.getString("challenge")
// 'challenge' is a technical identifier/token, not localizable text.
clientJson.put("challenge", BaseEncoding.base64Url()
.encode(challengeFromJson.toByteArray(StandardCharsets.UTF_8)))
clientJson.put("origin", clientDataJson.getString("origin"))
clientJson.put("type", clientDataJson.getString("type"))
clientJson.put("androidPackageName", clientDataJson.getString("androidPackageName"))
return BaseEncoding.base64().encode(clientJson.toString().toByteArray())
}
Orientações para usuários e preferências de autenticação
Uma parte central da estratégia de chaves de acesso da Zoho envolveu incentivar a adoção pelos usuários e oferecer flexibilidade para se alinhar a diferentes requisitos organizacionais. Isso foi possível com um design de interface cuidadoso e controles de política.
A Zoho reconheceu que as organizações têm necessidades de segurança variadas. Para isso, o Zoho implementou:
- Aplicação por administradores:no painel de administração do Zoho Directory, os administradores podem designar as chaves de acesso como o método de autenticação obrigatório e padrão para toda a organização. Quando essa política é ativada, os funcionários precisam configurar uma chave de acesso no próximo login e usá-la a partir de então.
- Escolha do usuário:se uma organização não aplicar uma política específica, os usuários individuais manterão o controle. Eles podem escolher o método de autenticação preferido durante o login, selecionando chaves de acesso ou outras opções configuradas nas configurações de autenticação.
Para tornar a adoção de chaves de acesso atraente e simples para os usuários finais, o Zoho implementou:
- Configuração fácil:o Zoho integrou a configuração de chaves de acesso diretamente ao app Zoho OneAuth para dispositivos móveis, disponível para Android e iOS. Os usuários podem configurar as chaves de acesso no app a qualquer momento, facilitando a transição.
- Acesso consistente:o suporte a chaves de acesso foi implementado em pontos de contato importantes do usuário, garantindo que eles possam se registrar e autenticar usando chaves de acesso por:
- O app Zoho OneAuth para dispositivos móveis (Android e iOS);
- A página de contas da Web do Zoho.
Esse método garantiu que o processo de configuração e uso de chaves de acesso fosse acessível e integrado às plataformas que já usam, independentemente de ter sido determinado por um administrador ou escolhido pelo usuário. Saiba como criar fluxos de usuários tranquilos para autenticação com chaves de acesso no guia de experiência do usuário com chaves de acesso.
Impacto na velocidade do desenvolvedor e na eficiência da integração
O Credential Manager, como uma API unificada, também ajudou a melhorar a produtividade dos desenvolvedores em comparação com fluxos de login mais antigos. Isso reduziu a complexidade de lidar com vários métodos de autenticação e APIs separadamente, levando a uma integração mais rápida, de meses para semanas, e menos erros de implementação. Isso simplificou o processo de login e melhorou a confiabilidade geral.
Ao implementar chaves de acesso com o Credential Manager, a Zoho alcançou melhorias significativas e mensuráveis em todos os aspectos:
-
Melhorias drásticas na velocidade
- Login duas vezes mais rápido em comparação com a autenticação de senha tradicional.
- Login quatro vezes mais rápido em comparação com nome de usuário ou número de celular com autenticação por OTP de e-mail ou SMS.
- Login seis vezes mais rápido em comparação com a autenticação por nome de usuário, senha e SMS ou senha única do autenticador.
-
Redução nos custos de suporte
- Redução dos pedidos de suporte relacionados a senhas, principalmente para senhas esquecidas.
- Redução de custos associados à 2FA baseada em SMS, já que os usuários atuais podem fazer a integração diretamente com chaves de acesso.
-
Adoção pelos usuários e segurança reforçada:
- Os logins com chaves de acesso dobraram em apenas quatro meses, mostrando uma alta aceitação dos usuários.
- Os usuários que migram para chaves de acesso ficam totalmente protegidos contra ameaças comuns de phishing e violação de senhas.
- Com um crescimento de 31% na adoção mês a mês, mais usuários se beneficiam diariamente da segurança aprimorada contra vulnerabilidades como phishing e troca de SIM.
Conselhos e práticas recomendadas
Para implementar chaves de acesso no Android, os desenvolvedores precisam considerar as seguintes práticas recomendadas:
-
Aproveite a API Credential Manager do Android:
- O Gerenciador de credenciais simplifica a recuperação de credenciais, reduzindo o esforço do desenvolvedor e garantindo uma experiência de autenticação unificada.
- Gerencia senhas, chaves de acesso e fluxos de login federados em uma única interface.
-
Garanta a consistência da codificação de dados ao migrar de outras soluções de autenticação FIDO:
- Mantenha a formatação consistente para todas as entradas/saídas ao migrar de outras soluções de autenticação FIDO, como chaves de segurança FIDO.
-
Otimize o tratamento de erros e a geração de registros:
- Implemente um tratamento de erros robusto para uma experiência do usuário perfeita.
- Forneça mensagens de erro localizadas e use registros detalhados para depurar e resolver falhas inesperadas.
-
Eduque os usuários sobre as opções de recuperação de chaves de acesso:
- Evite cenários de bloqueio orientando os usuários de forma proativa sobre as opções de recuperação.
-
Monitore as métricas de adoção e o feedback dos usuários:
- Acompanhe o engajamento dos usuários, as taxas de adoção de chaves de acesso e as taxas de sucesso de login para continuar otimizando a experiência do usuário.
- Faça testes A/B em diferentes fluxos de autenticação para melhorar a conversão e a retenção.
As chaves de acesso, combinadas com a API Android Credential Manager, oferecem uma solução de autenticação unificada e poderosa que aumenta a segurança e simplifica a experiência do usuário. As chaves de acesso reduzem significativamente os riscos de phishing, roubo de credenciais e acesso não autorizado. Incentivamos os desenvolvedores a testar a experiência no app e oferecer a autenticação mais segura aos usuários.
Começar a usar chaves de acesso e o Credential Manager
Aprenda a usar chaves de acesso e o Credential Manager no Android com nosso exemplo de código público.
Se você tiver dúvidas ou problemas, compartilhe com nossa equipe usando o Issue Tracker de credenciais do Android.
Continuar lendo
-
Estudos de caso
A Uber usou a API Android Restore Credentials para simplificar o login em novos dispositivos, projetando uma redução de 4 milhões de logins manuais por ano e aumentando a retenção de usuários.
Niharika Arora • Leitura de 5 minutos
-
Estudos de caso
De notícias de última hora e entretenimento a esportes e política, o X é um app de mídia social que ajuda quase 500 milhões de usuários no mundo todo a ter acesso a todas as informações com comentários ao vivo.
Niharika Arora • 3 min de leitura
-
Estudos de caso
O Monzo é um banco digital do Reino Unido com 15 milhões de clientes e crescendo. À medida que o app escalonava, a equipe de engenharia identificou o tempo de inicialização do app como uma área crítica para melhoria, mas se preocupou com a necessidade de mudanças significativas no codebase.
Ben Weiss • 2 min de leitura
Fique por dentro
Receba os insights mais recentes sobre desenvolvimento Android na sua caixa de entrada semanalmente.