Oferecer login e credenciais digitais sem complicações no Android

Olá!

Agradeço a participação de vocês hoje.

Hoje, vamos falar sobre o futuro da autenticação e da identidade digital.

Meu nome é Tom Colvin.

Sou CTO da Apptaura e GDE no Android. Estou aqui com Chiping Yeh, que é engenheiro sênior de relações com desenvolvedores Android no Google.

A senha tradicional está morta.

Ou, pelo menos, deveria ser.

Hoje, vou falar sobre um mundo sem senhas.

As senhas são uma vulnerabilidade bem conhecida na nossa infraestrutura de segurança.

Mesmo quando são armazenadas com segurança, elas são vulneráveis a phishing, violações de servidor e ataques automatizados, como ataque de preenchimento de credenciais.

Como setor, tentamos resolver isso aplicando complexidade: caracteres especiais, números, rotações obrigatórias.

As evidências mostram que isso falhou, em parte porque, quanto mais difícil você torna o processo, mais você, paradoxalmente, incentiva um comportamento inseguro.

Porque uma senha complexa que é alterada regularmente provavelmente será anotada em um post-it.

E até mesmo a autenticação de dois fatores baseada em SMS se mostrou vulnerável a interceptações, como a troca de chip.

Hoje, no entanto, esse problema está praticamente resolvido.

As chaves de acesso são baseadas nos padrões FIDO e usam criptografia de chave pública-privada.

Elas são altamente resistentes a phishing, não são expostas em uma violação de servidor e estão diretamente vinculadas à segurança do smartphone do usuário por meio do bloqueio de tela, que, na maioria dos casos, é baseado em biometria, impressões digitais etc. Além disso, elas melhoram ativamente a experiência do usuário com uma experiência unificada em todas as plataformas e sem a necessidade de lembrar senhas complexas.

Nosso manifesto hoje é simples.

Chegou a hora de migrar para um mundo sem senhas.

E as ferramentas para fazer isso já estão em nossas mãos.

O Gerenciador de credenciais do Jetpack é fundamental para fazer essa transição no Android.

Ele é compatível com versões anteriores até o Android 4.4, e com chaves de acesso desde o Android 9. Ele oferece uma API única e unificada que aceita chaves de acesso e autenticação tradicional, como login federado, como o Fazer login com o Google, incluindo um substituto para senhas, se necessário.

Você chama a API Credential Manager, e ela processa a interface para selecionar o método de autenticação que o usuário quer ver.

Em seguida, ela faz o trabalho pesado para retornar a credencial correta, obtida de forma segura.

Ele oferece suporte para login, inscrição e backup de credenciais.

E você pode usá-lo para atualizar e excluir credenciais.

Ele também ajuda os usuários a mover senhas e chaves de acesso entre provedores de credenciais com apenas alguns cliques, sem precisar fazer o download de arquivos.

Ele foi projetado para dar aos usuários controle total sobre os próprios dados e a liberdade de trocar de provedor sempre que necessário.

E o Gerenciador de credenciais oferece suporte a muitos formatos, incluindo relógios, TVs, XR, automóveis, smartphones, dobráveis e tablets.

E, o mais importante para nós, ele tem um fluxo dedicado para chaves de acesso.

Veja como é a experiência do usuário durante a inscrição.

Meu app informa ao Credential Manager que a autenticação por chave de acesso está disponível e fornece detalhes coletados do back-end.

Você clica em "Registrar", e o Gerenciador de Credenciais mostra uma página inferior com um comando de bloqueio de tela.

Isso geralmente é desbloqueado com biometria, como impressão digital ou reconhecimento facial.

O Credential Manager lida com o trabalho complexo de criptografia, como a criação da chave de acesso.

E ela salva a chave de acesso no meu Credential Manager, que, neste caso, é o Gerenciador de Senhas do Google, mas poderia ser outro.

O código vai ficar assim:

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

val createCredentialResponse =  credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

Primeiro, criamos esse objeto createPublicKeyCredentialRequest usando os detalhes fornecidos pelo back-end, que é este registerRequestJson.

Em seguida, chamamos o método mágico credentialManager.createCredential.

Transmitimos essa solicitação e o contexto local, o que permite mostrar a interface.

Aliás, observe que não precisei escrever nenhum código de interface aqui.

O Credential Manager cuida de tudo isso para nós.

Esse é o processo de login.

Para o usuário, ele é muito parecido com o processo de inscrição.

Basta um comando de desbloqueio e pronto.

Para desenvolvedores, as diferenças são pequenas.

val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
   requestJson = authenticationRequestJson
)
val signInRequest =
   GetCredentialRequest(listOf(getPublicKeyCredentialOption))

val result =  credentialManager.getCredential  (
   context = localActivity,
   request = signInRequest
)

Primeiro, recebemos os detalhes do login do back-end para criar uma instância GetPublicKeyCredential.

Informamos ao Credential Manager quais tipos de credenciais são aceitos.

Aqui, são apenas chaves de acesso.

Mas também podemos adicionar outros tipos de credenciais, se quisermos.

Em seguida, chamamos credentialManager.getCredential transmitindo essa lista de credenciais que acabamos de solicitar.

Novamente, sem código de interface.

Não é necessário escrever nenhum código de interface.

O Credential Manager cuida disso para nós.

Ele direciona o usuário para a opção mais usada, deixando as outras disponíveis como backup.

Isso resolve automaticamente um dos problemas de autenticação mais irritantes da atualidade.

Você notou?

Isso significa que ele lembra qual método usei para fazer login pela última vez.

Olha, a resposta está bem apresentada em uma página inferior.

Isso não é apenas um incômodo para o usuário.

É um ponto de atrito real.

Ela causa recuperações de conta desnecessárias e tem impacto comercial, como carrinhos de compras abandonados.

Este é o código do meu aplicativo de demonstração, que você pode usar para testar o Gerenciador de credenciais.

Você pode ver esses fluxos no seu próprio dispositivo.

E há os exemplos de código oficiais do Google à esquerda.

Isso processa a criação de chaves de acesso.

E quanto ao upgrade de usuários de senha para chaves de acesso?

Uma ferramenta poderosa para isso é a criação condicional.

Se o usuário acabou de fazer login usando a senha, e ela foi preenchida automaticamente por um provedor de credenciais compatível, sabemos que ele está interagindo ativamente e que a identidade dele foi verificada recentemente.

Nesse caso, a criação condicional permite solicitar a criação de uma chave de acesso automaticamente em segundo plano.

Ele não interrompe o fluxo de trabalho do usuário.

A chave de acesso é gerada silenciosamente e armazenada.

O Gerenciador de Senhas do Google mostra uma notificação para confirmar que isso aconteceu.

Outros gerenciadores de senhas podem funcionar de forma diferente.

O código para a criação condicional é muito parecido com o código para inscrição.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson,
   preferImmediatelyAvailableCredentials = false,
   isConditional = true
)

val createCredentialResponse = credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

A flag mágica é isConditional true, o que garante que o usuário não veja essa interface.

Como ele funciona de forma oportunista, vamos colocar isso em um try-catch.

Vamos lidar com os erros de forma silenciosa para não incomodar o usuário se o processo falhar.

Em seguida, a chave de acesso é salva no Credential Manager do usuário e fica disponível para a próxima vez.

O Credential Manager também permite que os provedores de credenciais importem e exportem as credenciais com segurança.

Com apenas alguns cliques.

Não é preciso fazer downloads.

Isso dá mais flexibilidade, mantendo as informações seguras.

O fluxo é assim.

No novo provedor de credenciais, o usuário solicita a importação de credenciais.

Em seguida, o Credential Manager processa a interface de importação, permitindo que o usuário selecione a origem dos dados de credenciais.

O provedor de credenciais de exportação pode fornecer a própria interface, o que permite educar o usuário e fornecer os avisos relevantes.

Por fim, o novo provedor de credenciais do usuário recebe os dados por um canal seguro.

Assim, é possível importá-lo sem qualquer interação do usuário.

Mas o que acontece se o usuário revogar uma chave de acesso do app ou site?

O provedor de credenciais não necessariamente sabe que isso aconteceu.

Na próxima vez que tentarem fazer login, o Credential Manager vai oferecer essa chave de acesso inativa, e eles vão ter apenas uma tentativa rejeitada.

Da mesma forma, quando um usuário atualiza o nome de usuário ou de exibição, é necessário fazer uma sincronização.

Agora, com a API Signal, seu app pode sinalizar esses estados específicos para o provedor de credenciais.

Por exemplo, considere o caso de login com uma senha revogada.

Seu app pode capturar esse estado de erro específico e usá-lo para informar o provedor de credenciais do usuário.

O provedor de credenciais pode se atualizar para que essa chave de acesso específica não seja oferecida.

Esses são alguns dos recursos do Credential Manager, que é muito útil para que os usuários se inscrevam usando chaves de acesso e para priorizar as chaves de acesso em relação a outros métodos ao fazer login.

Mas lembre-se de que nosso objetivo final é eliminar completamente as senhas.

Como o Gerenciador de credenciais ajuda com essa meta?

Este é o processo de cinco etapas que propomos.

Nas duas primeiras etapas, você faz upgrade dos usuários de senha para chaves de acesso.

Primeiro, tentamos de forma oportunista, usando a criação condicional.

Se essa oportunidade não surgir, vamos precisar da intervenção do usuário. Por isso, enviamos convites no app pedindo que os usuários configurem uma chave de acesso.

Podemos começar a mostrá-los gradualmente com cada vez mais destaque.

Afinal, da perspectiva do usuário, geralmente basta fornecer o bloqueio de tela, como a biometria.

Quando as análises mostrarem que a grande maioria dos usuários tem contas que usam chaves de acesso, elas poderão ser obrigatórias para todos os novos usuários.

Mas esses usuários antigos são os que lidamos nessas últimas três etapas.

Recomendamos que os usuários de chaves de acesso removam as senhas.

Por isso, na etapa 3, permitimos que eles façam isso manualmente, com uma opção muito clara de excluir a senha nas configurações da conta.

Na etapa 4, começamos a incentivar a exclusão de senhas usando, por exemplo, notificações no app, acompanhadas de textos educativos.

Por fim, você muda a exclusão de senhas de ativação para desativação.

Por fim, até mesmo essa última opção de desativação pode desaparecer.

O Analytics vai nos dar confiança para remover completamente os fluxos de senha do app.

Portanto, a transição para um mundo sem senhas não é mais um conceito de segurança teórico para o futuro.

Ele é amplamente compatível.

As APIs são robustas, e a experiência do usuário é excelente.

Recomendo que você comece a integrar os fluxos de chaves de acesso ao Gerenciador de Credenciais hoje mesmo.

Comece a fazer o upgrade dos seus usuários e deixe as senhas no passado.

Nossa equipe agradece.

Agora, vou passar a palavra para Chiping, que vai falar sobre a próxima evolução na migração e identidade de dispositivos.

Legal.

Certo, obrigada, Tom.

Como o Tom destacou, a autenticação integrada nos dispositivos dos usuários é fundamental.

Mas o que acontece quando um usuário compra um smartphone novo?

Hoje, a maior queda na jornada do usuário geralmente acontece quando ele troca de dispositivo.

Hoje, quero falar sobre como estamos resolvendo isso e abordar rapidamente um requisito futuro da Google Play Store sobre a restauração de credenciais.

A partir de abril de 2027, o Google Play vai exigir que os apps atendam aos requisitos de login sem toque para manter todos os recursos de publicação e a visibilidade ideal na Google Play Store.

O que é o login sem toque?

Isso significa que os usuários não precisam se autenticar manualmente no app ao trocar de dispositivo.

Como implementar isso?

O método principal que recomendamos para fazer isso é a API Restore Credentials do Android pelo Gerenciador de credenciais.

Com essa API, é possível gerar uma chave de restauração, que é salva no dispositivo do usuário ou na nuvem com base nas configurações de backup dele.

Recomendamos gerar essa chave em segundo plano depois que o usuário fizer login.

Neste diagrama, ilustramos um usuário fazendo login no app.

Em seguida, a chave de restauração é criada enquanto o usuário está usando o app.

Essa chave é armazenada localmente ou, se ativada, remotamente na nuvem.

Quando o usuário configura o novo dispositivo, a credencial de restauração é transferida silenciosamente em segundo plano durante o processo de configuração.

Os usuários podem restaurar dados da nuvem ou fazer uma transferência de dispositivo para dispositivo.

Em seguida, quando o app for aberto, você poderá chamar a API Credential Manager para usar essa chave de restauração e fazer login do usuário no novo dispositivo na primeira inicialização.

Isso permite que o usuário faça login no app de forma rápida e segura.

Se você quiser que o app seja restaurado imediatamente após a configuração sem ser aberto, implemente um agente de backup personalizado para fazer isso.

Isso permite que o usuário faça login no app sem precisar abri-lo manualmente.

Alguns dos nossos parceiros já implementaram isso nos apps deles.

A Uber é a maior empresa de transporte por aplicativo do mundo, oferecendo transporte para milhões de pessoas, além de apoiar a entrega de comida, o transporte de saúde e a logística de frete.

A simplicidade de acesso é crucial.

E, ao trocar de dispositivo, eles esperam uma transição tranquila, sem precisar fazer login novamente no app da Uber ou passar pela autenticação única por SMS todas as vezes.

Essa troca frequente de dispositivos é um desafio para a retenção de usuários.

Após uma avaliação da demanda dos usuários e da prototipagem de código, a Uber introduziu o suporte à API Restore Credentials no app Uber Rider, e os resultados foram muito positivos.

A estimativa é que isso vai economizar 4 milhões de logins diários médios por dia, e esse número deve aumentar à medida que a adoção crescer.

Confira este QR code e o link para saber mais sobre essa política e como seu app pode atender aos requisitos de restauração com zero toque.

Isso vai acontecer em abril de 2027, então marque essa data na sua agenda.

Se quiser começar a implementar as credenciais de restauração no seu app, use este QR code e o link para acessar nossa habilidade de credenciais de restauração.

Essa habilidade pode ser usada para ajudar a desenvolver ou testar rapidamente o recurso com o agente de sua escolha.

Agora, vamos falar sobre o futuro da identidade digital: a API Digital Credentials pelo Gerenciador de Credenciais.

Vamos entender o que são as credenciais digitais e como elas funcionam.

As credenciais digitais são documentos digitais verificáveis por criptografia que os usuários podem usar para fornecer informações sobre si mesmos.

Esses documentos são armazenados em carteiras digitais no dispositivo do usuário e podem ser solicitados por outros apps no dispositivo ou apresentados ao mundo de maneira híbrida, como por um QR code.

Os usos são amplos e variados, desde a verificação de identidade até o acesso a serviços e a compra de itens on-line.

As credenciais digitais oferecem uma maneira segura e prática de compartilhar informações sem precisar de cartões físicos.

As credenciais digitais envolvem três partes: o emissor, o titular e o verificador.

A vida de uma credencial digital geralmente flui da esquerda para a direita.

Vamos analisar cada uma dessas entidades e o papel que elas desempenham.

O primeiro é o emissor, que, como o nome indica, é uma parte que emite uma credencial, assim como o governo emite seu passaporte.

No entanto, no mundo digital, para evitar falsificações, essas credenciais também são assinadas pelo emissor com o certificado digital dele. Assim, qualquer pessoa que receber a credencial pode saber exatamente de quem ela é.

Na verdade, qualquer pessoa pode ser um emissor, seja uma academia, um hotel ou até mesmo você.

Basta criar uma credencial e assiná-la.

O emissor cria e emite credenciais, mas elas precisam ser armazenadas em algum lugar, assim como você precisa guardar seu documento de identidade oficial na sua carteira.

Esta é a próxima parte, chamada de titular, que também é descrita como uma carteira digital.

Os titulares, como o nome indica, armazenam principalmente as credenciais emitidas pelos emissores.

Eles ficam em um app no dispositivo e podem ser apresentados às partes solicitantes.

Da mesma forma que os emissores, qualquer pessoa pode ser um titular.

Na verdade, é comum que os emissores e os titulares sejam gerenciados pela mesma entidade.

Por exemplo, uma academia que quer criar e gerenciar uma credencial de associação digital no próprio app.

Nesse caso, você seria o emissor e o titular ao mesmo tempo.

O terceiro é o verificador, ou seja, a parte que solicita as credenciais digitais.

Os verificadores fazem solicitações de credenciais geralmente para verificar atributos de um usuário, como restrições de idade, sobrenome etc.

São as empresas ou apps que precisam de mais dados do usuário para realizar um serviço, como comprar bebidas alcoólicas ou verificar uma idade mínima.

No Android, as interações entre essas três partes e o usuário são coordenadas pelo Credential Manager com a API Digital Credentials.

O emissor pode chamar a API para emitir credenciais para um titular, embora isso seja desnecessário se eles forem a mesma entidade.

Depois que a credencial é emitida, um verificador pode chamar uma API para solicitá-la.

O Gerenciador de credenciais compara a solicitação com todos os titulares disponíveis e os apresenta ao usuário para que ele selecione a credencial e dê o consentimento.

Depois que um titular é selecionado, ele é invocado e pode fazer outras verificações, se necessário, antes de compartilhar a credencial com o verificador.

Depois que o verificador recebe a credencial, ele também pode realizar várias verificações sobre a legitimidade dela, incluindo a verificação do emissor original.

Agora, você deve estar se perguntando: como as credenciais digitais são seguras?

A segurança é integrada a cada etapa do processo, e vamos falar sobre algumas delas agora.

Portanto, do lado do emissor, quando ele quer compartilhar uma credencial com um titular, precisa verificar se o titular não pode ser adulterado ou copiado, ou seja, se ele é confiável.

Como ela pode verificar isso?

Antes de liberar a credencial, o emissor precisa que o titular comprove a própria identidade e a segurança do dispositivo em que está operando.

O titular envia o atestado da carteira, geralmente como uma cadeia de certificados verificável.

O titular também gera um par de chaves vinculado ao hardware.

Ele envia ao emissor a chave pública desse par de chaves com o atestado de chave do Android, para que o emissor possa validar a legitimidade do hardware.

O emissor vai assinar essa chave pública na credencial emitida, para que ela seja oficialmente vinculada ao dispositivo único.

Do lado do titular, quando ele tem uma nova credencial, ele registra apenas os metadados dela no Credential Manager.

O Credential Manager usa esses metadados para determinar quais titulares mostrar quando um verificador faz uma solicitação de credencial.

Nenhum dado real do usuário é registrado no Gerenciador de credenciais ou exposto ao Google.

Mesmo quando o Credential Manager está selecionando carteiras para mostrar ao usuário, o conteúdo de cada carteira não é revelado nesse momento.

Agora, quando uma solicitação de credencial é feita e um usuário consente em compartilhar uma credencial, o titular selecionado é invocado, e o controle do fluxo de trabalho é entregue a ele.

Como você deve se lembrar, um titular é apenas um app, então ele é invocado.

Nesse momento, o titular pode ver informações como o verificador solicitante e a credencial solicitada, além de decidir se quer compartilhar essa credencial com o verificador, mesmo que o usuário já tenha dado permissão.

Os dados da credencial em si não são acessíveis ao Google.

Apenas os metadados de roteamento são registrados, e o payload é criptografado de ponta a ponta entre o titular e o verificador.

Isso dá ao titular o controle sobre com quem ele quer compartilhar as credenciais.

Por fim, do lado do verificador, depois que a credencial é solicitada e o titular a compartilha, o verificador recebe a apresentação da credencial de um titular.

Agora, o verificador pode conferir se a resposta foi gerada recentemente pelo titular original da credencial para a solicitação.

Ele pode confirmar que a resposta da credencial foi assinada usando a chave vinculada ao dispositivo do titular, incluindo a solicitação de um token de uso único e a origem da chamada observada pelo titular.

O verificador também pode conferir a autenticidade do emissor da credencial verificando o certificado dele, garantindo que ele veio de uma fonte confiável.

Em resumo, os emissores recebem garantias de hardware, os titulares controlam quais credenciais querem compartilhar, os verificadores recebem provas criptográficas do emissor e do titular, e os usuários mantêm o consentimento total sobre quais dados querem compartilhar.

Agora que já falamos sobre a segurança das credenciais digitais, vamos conhecer alguns casos de uso disponíveis atualmente com a API Digital Credentials no Android.

A primeira que vou abordar é a verificação de e-mail.

Essa API usa o Gmail conectado do usuário diretamente do dispositivo e o apresenta como uma credencial digital verificada pelo Google para seu app, eliminando a necessidade de enviar senhas únicas ou links mágicos.

Isso significa que o usuário nunca sai do app e só precisa dar consentimento com um toque na página inferior conhecida do Gerenciador de credenciais.

Confira uma gravação de demonstração da API em ação.

Este é um app de exemplo que implementa a verificação de e-mail usando a API Digital Credentials.

Quando eu tocar em "Solicitar e-mail verificado", o Gerenciador de Credenciais vai pedir uma credencial digital de e-mail verificado aos titulares no dispositivo que têm esse tipo de credencial.

Nesse caso, apenas o Google é o titular dessa credencial de e-mail verificado, que aparece na página inferior.

Este é um dos e-mails que o usuário usou para fazer login no dispositivo.

Nesse caso, o Google é o emissor e o titular da credencial digital.

Depois que eu seleciono a credencial que quero compartilhar, ela é retornada ao app, que atualmente exibe apenas os campos contidos na credencial, que é o e-mail verificado.

No app, use essas informações para prosseguir para a próxima tela, como a criação de uma chave de acesso ou outras etapas de criação de conta.

Para o usuário, é tão simples quanto dar o consentimento e passar para a próxima tela.

Se quiser testar, acesse nosso exemplo do GitHub e instale-o no seu dispositivo.

Tente usar em um dispositivo físico e faça login em pelo menos uma conta do Gmail no dispositivo.

Então, vou dar um pouco mais de tempo se as pessoas estiverem interessadas.

Certo.

Incrível, não é?

E quando você pensa em verificação de e-mail, qual é a próxima forma de verificação de usuário que vem à mente?

Isso mesmo, verificação de número de telefone.

A API Digital Credentials também oferece suporte nativo à verificação de número de telefone, eliminando o atrito e a vulnerabilidade das OTPs por SMS.

A verificação de número de telefone também funciona pela API Digital Credentials. Nesse caso, o número de telefone no dispositivo é solicitado e apresentado como uma credencial digital.

O usuário só vê a página inferior do Credential Manager para compartilhar ou verificar o número de telefone, sem sair do app, e precisa de apenas alguns toques para concluir a verificação.

Aqui, você vê um exemplo de app em que o cliente pode compartilhar o número de telefone com um único toque, sem sair do app.

Como funciona essa configuração?

Se mapearmos isso para as partes da credencial digital, o emissor, neste caso, é a operadora do número de telefone no chip do dispositivo, e o titular é a Android Telephony.

Quando um verificador, como seu app, solicita o número de telefone do usuário, ele é recuperado da Google Telephony com uma chamada de API Digital Credentials.

Você deve estar se perguntando como funciona o faturamento.

Há uma etapa extra exclusiva desse fluxo, em que a credencial é transmitida à operadora ou ao agregador para fins de faturamento.

Isso acontece depois que o número de telefone é recuperado da Google Telephony, onde é armazenado em um estado criptografado.

Em seguida, ele é transmitido para a operadora, que descriptografa e retorna o número de telefone diretamente para o back-end do app. Durante esse processo, você recebe uma cobrança.

O bom disso é que a operadora só vai cobrar pelas verificações concluídas, que são transferidas por dados móveis ou Wi-Fi e são muito mais confiáveis do que o SMS.

Aqui, temos uma demonstração da verificação de número de telefone em ação, usando o Firebase como agregador de operadoras.

O app pede o número de telefone do usuário como parte do processo de login.

Esse usuário tem vários chips e escolhe um para compartilhar com o app.

Depois que o usuário confirma a escolha, a troca acontece em segundo plano.

Em seguida, você verá a próxima tela com o número de telefone recuperado preenchido.

O usuário não precisou sair do app, apenas selecionar e confirmar o número de telefone para compartilhar e avançar no fluxo sem problemas, tudo em poucos toques.

Vamos esperar o processo terminar para que você possa ver a conclusão mais uma vez.

E você vê o número de telefone na tela final.

Pronto.

Falamos sobre muitas coisas hoje.

Primeiro, mostramos como usar o Gerenciador de credenciais para melhorar a implementação de chaves de acesso e migrar para um mundo sem senhas.

Confira nossos recursos sobre o Gerenciador de credenciais e as chaves de acesso aqui para saber mais e acessar nossos apps de exemplo.

Em seguida, falamos sobre o próximo requisito de login com um toque para seus apps, que facilita o login dos usuários ao configurar um novo dispositivo.

Isso será obrigatório na Google Play Store até abril de 2027, então marque essa data no seu calendário.

Por fim, abordamos como as credenciais digitais funcionam e alguns dos recursos mais úteis no Android.

Confira nossos recursos sobre credenciais digitais aqui para uma investigação mais aprofundada sobre o conteúdo e acesso aos nossos exemplos.

Tudo o que compartilhamos hoje está disponível e pronto para você usar.

O futuro da identidade no Android chegou e está mais empolgante do que nunca.

Agradeço pelo seu tempo. Sei que é hora do almoço, então aproveite a comida lá fora.

E não tenha medo de me procurar ou falar com o Tom se tiver dúvidas sobre chaves de acesso ou credenciais digitais.

Até logo.