Passkeys em Aplicações Nativas: Implementação Nativa vs. WebView

Este artigo explica como implementar passkeys em aplicativos nativos (iOS + Android). Você aprenderá qual tipo de WebView é recomendado para autenticação com passkeys.

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. Opções de Implementação de Passkeys em Aplicações Nativas#

A autenticação é o pilar que protege os dados do usuário e garante interações seguras em aplicativos nativos. O advento das passkeys revolucionou este espaço, oferecendo um mecanismo de autenticação robusto e de fácil utilização. Existem duas formas principais de integrar passkeys em um aplicativo nativo: através de uma implementação nativa ou via WebView. Vamos primeiro dar uma olhada e ver como as duas formas se comparam.

1.1 Implementação Nativa: Ótima UX#

Uma implementação nativa é frequentemente vista como a que proporciona a melhor experiência do usuário (UX) dentro de um aplicativo. É caracterizada por suas interações de usuário suaves, integradas e coesas, adaptadas precisamente ao ambiente do sistema operacional, seja iOS ou Android. O requisito para uma implementação 100% nativa é tornar-se 100% sem senha e ser verdadeiramente nativo em passkeys. Esta abordagem liberta-o do atrito potencial da transição entre o aplicativo nativo e o conteúdo web (exibido através de uma WebView).

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

1.2 Implementação com WebView: Experiência Semelhante a um Navegador#

Ao desenvolver um aplicativo nativo, o caminho para se tornar totalmente nativo nem sempre é possível. Em cenários onde você ainda precisa suportar autenticação baseada em senha utilizando OAuth2, uma integração totalmente nativa pode não ser viável, tornando as implementações de WebView a única alternativa viável. A WebView atua como uma ponte, incorporando conteúdo web diretamente no seu aplicativo, proporcionando uma UX semelhante à de um navegador ao navegar por páginas web. Isto é particularmente pertinente se você mesmo for um provedor de OAuth2, se a sua solução de autenticação subjacente for baseada em OAuth2 ou se a sua solução de login usar logins sociais através de terceiros, como Google ou GitHub. Nestes casos, empregar uma WebView torna-se inevitável devido à necessidade de interagir com conteúdo web e gerenciar vários fluxos de autenticação de usuário, especialmente quando associações de aplicativos nativos são necessárias.

Em essência, embora as implementações nativas ofereçam uma experiência de usuário suave e inigualável, elas podem nem sempre ser uma opção viável, especialmente quando combinadas com soluções de autenticação baseadas em senha ou OAuth2. Por outro lado, as implementações de WebView fornecem um caminho flexível, embora um pouco menos integrado, para incorporar conteúdo web e gerenciar a autenticação de usuário dentro do seu aplicativo, garantindo que você possa navegar pelas complexidades de vários fluxos de autenticação e logins de terceiros.

As próximas seções deste artigo focam na implementação via WebView. Para saber mais sobre a integração nativa de passkeys, por favor, veja aqui.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

Mais de 10.000 desenvolvedores confiam na Corbado e tornam a Internet mais segura com passkeys. Tem perguntas? Escrevemos mais de 150 posts de blog sobre passkeys.

Junte-se à Comunidade Passkeys

2. Visão Geral das Opções de WebView#

Navegando pelo labirinto da autenticação em aplicativos nativos, desenvolvedores e gerentes de produto encontram uma decisão crucial: implementar a autenticação com passkeys nativamente ou via WebView. Se a decisão for pela segunda opção, tanto as plataformas iOS quanto Android oferecem dois tipos distintos de WebViews, cada um com seus atributos únicos e casos de uso potenciais.

2.1 WebViews do iOS#

WKWebView
SFSafariViewController
SFAuthenticationSession / ASWebAuthenticationSession (especificamente adaptado para fluxos de autenticação baseados em OAuth / OpenID Connect)

Nas seções seguintes, aprofundamos esses tipos de WebView e, por fim, guiamos você para uma decisão informada sobre qual WebView empregar para a autenticação com passkeys em seus aplicativos nativos (se a implementação puramente nativa não for uma alternativa).

Subscribe to our Passkeys Substack for the latest news.

3. WebViews no iOS#

As WebViews do iOS são ou WKWebView ou SFSafariViewController (se estiver trabalhando com OAuth / OIDC, é SFAuthenticationSession / ASWebAuthenticationSession).

Para testar o comportamento das diferentes WebViews no iOS, recomendamos o aplicativo WebView - WKWebView and UIWebView rendering.

3.1 WKWebView#

WKWebView é uma opção de WebView poderosa e versátil disponível para desenvolvedores iOS. Introduzida com o iOS 8, ela permite que os desenvolvedores incorporem conteúdo web diretamente em um aplicativo, fornecendo uma vasta gama de opções de personalização e configuração. A WKWebView é conhecida por seu desempenho, utilizando o mesmo motor de renderização web do Safari, e oferecendo um rico conjunto de APIs para interagir com conteúdo web, gerenciar navegação, interações do usuário e muito mais.

3.2 SFSafariViewController#

SFSafariViewController é uma WebView que permite aos desenvolvedores aproveitar as capacidades do Safari diretamente em seus aplicativos. Ele proporciona uma experiência de usuário contínua ao utilizar as configurações do Safari do usuário, como senhas salvas, passkeys, cookies e mais, garantindo uma navegação web consistente, porque na verdade ele roda como o aplicativo Safari. O SFSafariViewController não é tão personalizável quanto o WKWebView, mas oferece recursos de segurança aprimorados e facilidade de uso, tornando-o uma escolha preferida para exibir conteúdo web direto nos aplicativos.

	WKWebView	SFSafariViewController
Experiência do usuário	- Sensação nativa: Os usuários podem sentir que o conteúdo da web é uma parte nativa do aplicativo porque os desenvolvedores podem personalizar a aparência para combinar com o design do aplicativo. - Preenchimento automático: O preenchimento automático com dados do Safari é possível	- Contínua: Experiência de usuário contínua usando as configurações do Safari do usuário, garantindo uma navegação web consistente entre o aplicativo nativo e o navegador.
Experiência do desenvolvedor	- Altamente personalizável: Ampla personalização e configuração disponíveis - Flexível: Muitas APIs para interagir com o conteúdo da web	- Personalização média: Opções de personalização limitadas, especialmente em comparação com o WKWebView, - Simples: Mais simples de implementar em comparação com o WKWebView
Desempenho	- Relativamente lento: Dependendo da implementação e do conteúdo da web, as velocidades de carregamento podem ser otimizadas, mas ainda podem ser mais lentas em comparação com o SFSafariViewController devido ao processamento adicional de recursos e interações personalizadas.	- Relativamente rápido: Normalmente oferece melhor desempenho, pois aproveita o motor do Safari, que é otimizado para velocidade e eficiência, proporcionando tempos de carregamento rápidos para páginas da web.
Confiança e reconhecimento	- Exibição de URL não obrigatória: O WKWebView muitas vezes não mostra a URL, tornando mais difícil para os usuários verificarem a página da web. Potencial para aplicativos maliciosos imitarem esse comportamento e fazerem phishing de credenciais.	- Experiência semelhante a um navegador: Renderiza páginas da web usando o Safari, proporcionando uma experiência "semelhante a um navegador". Os usuários podem ver a URL и acessar os recursos de preenchimento automático do Safari, potencialmente inspirando mais confiança devido à interface familiar.
Isolamento	- Separados: Cookies e sessões são separados do Safari; os usuários não serão automaticamente logados em um WKWebView.	- Separados: Cookies e sessões são separados do Safari; os usuários também não serão automaticamente logados no SFSafariViewController.
Vulnerabilidades	- Seguro: Intrinsecamente seguro devido ao sandboxing de aplicativos da Apple, mas o comportamento e a segurança dependem da implementação do aplicativo. Vulnerabilidades potenciais se não for implementado corretamente.	- Mais Seguro: Beneficia-se dos recursos de segurança integrados do Safari, incluindo avisos anti-phishing e de sites maliciosos. Geralmente considerado mais seguro para exibir conteúdo da web do que o WKWebView devido a esses recursos e à familiaridade do usuário com o Safari.
Outros	- Recursos não disponíveis: Alguns recursos do navegador (por exemplo, WebAuthn) podem não estar totalmente acessíveis devido a preocupações de segurança e ao fato de o WKWebView rodar no contexto do aplicativo. - Injeção de JavaScript: Alguns aplicativos, como o TikTok, injetam JavaScript de rastreamento em seu WKWebView no aplicativo, ou restringem o controle do usuário (por exemplo, Facebook) - Questões de privacidade: Mais feedback da comunidade sobre privacidade	- Sem injeção de JavaScript: Não permite a execução de JavaScript a partir do aplicativo, aumentando a segurança e a privacidade. Também não suporta alertas ou confirmações de JavaScript, o que pode impactar a experiência do usuário em certas páginas da web. - Modo de Leitura: Fornece um modo de leitura para uma versão limpa e fácil de ler de artigos.

3.3 SFAuthenticationSession / ASWebAuthenticationSession#

SFAuthenticationSession e ASWebAuthenticationSession são WebViews especificamente adaptadas para fluxos de autenticação baseados em OAuth / OpenID Connect. Elas fornecem um espaço seguro e isolado para a autenticação do usuário, protegendo as credenciais do usuário e garantindo que informações privadas não sejam inadvertidamente compartilhadas com o aplicativo. Essas sessões compartilham cookies e dados de sites com o Safari, proporcionando uma experiência de usuário consistente e contínua, especialmente durante os processos de autenticação.

Prós:

Autenticação Dedicada: Projetado especificamente para fluxos de autenticação baseados em OAuth / OpenID Connect, garantindo um processo de autenticação simplificado.
Proteção de Privacidade: Garante a privacidade dos dados do usuário ao não compartilhar cookies ou dados de sites com o aplicativo.
Suporte a SSO: Suporta Single Sign-On, proporcionando uma experiência de usuário conveniente.

Contras:

Caso de Uso Limitado: Focado principalmente na autenticação OAuth / OpenID Connect, o que pode não ser adequado para todos os casos de uso.

Quando a tarefa principal é a autenticação do usuário, especialmente ao implementar SSO ou interagir com provedores de OAuth, você deve usar SFAuthenticationSession / ASWebAuthenticationSession em vez de SFSafariViewController.

Want to find out how many people use passkeys?

View Adoption Data

4. WebViews no Android#

As WebViews do Android são ou WebView ou Chrome Custom Tabs (CCT). Para testar o comportamento das diferentes WebViews no Android, recomendamos o aplicativo WebView vs Chrome Custom Tabs.

4.1 Android WebView#

A WebView no Android é um componente abrangente que permite aos desenvolvedores exibir conteúdo web como parte da UI do aplicativo. É versátil, oferecendo uma ampla gama de opções de personalização e proporcionando aos desenvolvedores a flexibilidade de configurar a WebView para atender a várias necessidades. A WebView fornece um rico conjunto de APIs para interagir com conteúdo web, gerenciar interações do usuário e até mesmo lidar com diálogos de JavaScript, certificados de cliente e solicitações de permissão.

4.2 Chrome Custom Tabs (CCT)#

As Chrome Custom Tabs (CCT) oferecem uma maneira contínua, segura e eficiente de integrar conteúdo web diretamente em seu aplicativo. Ao aproveitar as capacidades e os recursos de segurança do Chrome, as CCT proporcionam uma experiência de usuário que é tanto consistente quanto de alto desempenho.

As CCT são um componente do navegador Chrome, projetado para se integrar com o framework do Android, permitindo que os aplicativos abram conteúdo web em um processo leve e dedicado. Notavelmente, ele abre mais rápido que um navegador convencional e, quando pré-carregado através de sua chamada de aquecimento, potencialmente supera uma WebView. Embora execute JavaScript, ele opera em seu próprio processo, protegendo os aplicativos da execução de código malicioso. Além disso, a UI das CCTs fornece uma barra de ação, exibindo a URL e um ícone de cadeado de verificação SSL para páginas seguras, tranquilizando assim os usuários sobre a autenticidade e segurança da página que está sendo carregada.

Em geral, pode-se dizer que a iOS WKWebView e a Android WebView, bem como o SFSafariViewController e as Chrome Custom Tabs (CCT) são semelhantes.

Recurso	WebView	Chrome Custom Tab
Experiência do usuário	- Flexibilidade: Fornece um rico conjunto de APIs para interagir com conteúdo da web e gerenciar interações do usuário, incluindo o tratamento de diálogos de JavaScript e solicitações de permissão. - Consistência: Gerenciar uma UX consistente, especialmente com conteúdo da web variado, pode ser desafiador.	- Recursos do Navegador: Compartilha recursos como Economia de Dados e preenchimento automático sincronizado entre dispositivos. - Botão Voltar: Permite que os usuários retornem facilmente ao aplicativo com um botão de voltar integrado. - Dependência: Depende do aplicativo Chrome, que pode não estar disponível ou atualizado em todos os dispositivos do usuário - Redirecionamento para o Navegador: Certas funcionalidades podem redirecionar os usuários para o aplicativo Chrome, potencialmente interrompendo a experiência do usuário. - Abas Personalizadas Parciais: Apenas uma parte da tela pode ser usada para a Chrome Custom Tab enquanto o resto mostra o aplicativo nativo - Painel lateral: No modo paisagem e em dispositivos de tela grande, a Chrome Custom Tab é exibida apenas em um lado da tela, enquanto o resto da tela mostra o aplicativo nativo
Experiência do desenvolvedor	- Altamente Personalizável: Oferece extensas opções/necessidades de personalização. - Interatividade: Fornece inúmeras APIs para interagir com conteúdo da web e gerenciar interações do usuário.	- Personalizável: Permite a personalização da cor da barra de ferramentas, botão de ação, barra de ferramentas inferior, itens de menu personalizados e animações de entrada/saída. - Callback: Entrega um callback para o aplicativo após uma navegação externa. - Recursos de Segurança: Fornece recursos prontos para uso, eliminando a necessidade de gerenciar solicitações, concessões de permissão ou armazenamento de cookies.
Desempenho	- Desempenho Mediano: Pode não oferecer o mesmo nível de desempenho das Chrome Custom Tabs (CCT)	- Pré-aquecimento: Inclui o pré-aquecimento do Navegador em segundo plano e o carregamento especulativo de URLs para melhorar o tempo de carregamento da página. - Prioridade: Impede que aplicativos que lançam uma Custom Tab sejam despejados durante seu uso, elevando sua importância para o nível de "primeiro plano".
Confiança e reconhecimento	- URL e SSL não Visíveis: A URL e as informações de SSL não são inerentemente visíveis em uma WebView. A menos que o desenvolvedor do aplicativo implemente esses recursos, os usuários não saberão se estão no site correto ou em um de phishing.	- URL e SSL Visíveis: Usa o navegador Chrome real para renderizar páginas. Os usuários podem ver a URL e o certificado SSL (indicando se a conexão é segura). Isso pode fornecer aos usuários a confiança de que não estão em um site de phishing.
Isolamento	- Executa dentro do Processo do Aplicativo: Se um aplicativo tiver uma vulnerabilidade que permita a execução de código malicioso, há o risco de que a WebView possa ser comprometida. No entanto, a WebView também recebe atualizações, mas seu comportamento e segurança podem depender mais do aplicativo que a utiliza. - Sem Compartilhamento de Cookie / Sessão: Não compartilha cookies ou sessões com o navegador principal do dispositivo, oferecendo isolamento, mas possivelmente exigindo que os usuários façam login novamente.	- Executa dentro do Processo do Chrome: Sendo parte do Chrome, as Custom Tabs rodam no mesmo processo e têm as mesmas atualizações de segurança e recursos do Chrome. - Compartilhamento de Cookies e Modelo de Permissões: Garante que os usuários não precisem fazer login novamente em sites ou conceder permissões novamente. - Configurações e Preferências do Chrome: Utiliza as configurações e preferências do Chrome.
Vulnerabilidades	- Callbacks para Roubar Credenciais: Vulnerabilidades potenciais incluem que às vezes o JavaScript é necessário, o que abre a porta para outros aplicativos executarem código malicioso, como registrar callbacks que tentam interceptar nomes de usuário e senhas. - Phishing: Além disso, um aplicativo malicioso pode abrir outra página da web que imita o fluxo do Link em uma tentativa de phishing.	- Navegação Segura do Google: Emprega a Navegação Segura do Google para proteger tanto o usuário quanto o dispositivo de sites perigosos. - Decoração Segura do Navegador: Garante que o usuário sempre veja a URL exata com a qual está interagindo e possa visualizar as informações do certificado do site, reduzindo o risco de phishing. Além disso, as abas personalizadas não permitem a injeção de JavaScript.
Outros	- O Google baniu WebViews para login de usuários em contas do Google

5. Recomendação para Implementação de Passkeys em Aplicações Nativas#

Nossos clientes nos perguntam continuamente sobre como as passkeys devem ser implementadas em aplicativos nativos. Em grande parte, esses clientes podem ser divididos em diferentes grupos:

Grupo A:

Clientes que estão começando a construir seu aplicativo nativo do zero e podem usar diretamente nossa autenticação sem senha (não existem senhas legadas).

Grupo B:

Clientes com usuários existentes e uma solução de autenticação existente. Muitas vezes, eles também já têm um aplicativo web existente que também precisa adicionar passkeys ao seu processo de autenticação. Aqui, muitas empresas decidem seguir um processo de duas etapas:

Adicionar passkeys ao seu fluxo de autenticação WebView existente (foi assim que o Google e o GitHub implementaram em seus aplicativos nativos)
Adicionar passkeys via implementação nativa por cima. Esta implementação nativa de passkey verifica antes da antiga WebView (por exemplo, para logins sociais e senhas) se o usuário pode fazer login com uma passkey (foi assim que o KAYAK implementou em seu aplicativo nativo).

Determine seu Grupo

Para fornecer aos seus usuários a melhor implementação de passkey em um aplicativo nativo, você precisa decidir a qual grupo pertence, com base na sua configuração técnica atual и como deseja promover as passkeys (esta questão é relevante para empresas do grupo B).

Recomendação para o Grupo A: Implementação Nativa

Se você está construindo um aplicativo totalmente novo (grupo A), recomendamos optar por uma implementação nativa de passkeys e se tornar completamente sem senha desde o início (ou seja, nenhum tipo de WebView é usado). Por favor, use os SDKs e APIs nativos para iOS e Android (por exemplo, através do pacote Flutter de passkeys). Por favor, leia também este artigo sobre Relying Party IDs.

Recomendação para o Grupo B: Primeiro WebView, depois Implementação Nativa

Se você não pode implementar passkeys nativamente hoje por qualquer motivo (grupo B), pode começar com uma implementação de WebView e, no futuro, migrar para uma implementação nativa de passkeys (isso funciona através da criação de arquivos de associação, como o apple-app-site-association para aplicativos iOS e o assetlinks.json para aplicativos Android). As razões para optar pela implementação com WebView podem incluir:

Você já oferece autenticação baseada em OAuth2 e quer continuar a oferecê-la aos seus usuários (OAuth2 não funciona nativamente, veja o padrão aqui)
Você quer oferecer autenticação com passkeys na mesma janela / tela onde oferece seus outros métodos de autenticação (por exemplo, senhas, logins sociais, OAuth2)

Esta é a forma como o Google ou o GitHub implementaram a autenticação com passkeys em seus aplicativos nativos atualmente. Por favor, veja a recomendação abaixo para configurar WebViews corretamente para autenticação com passkeys. No entanto, recomendamos considerar uma implementação nativa de passkeys como o KAYAK fez e começar diretamente com a etapa 2.

Se você pertence ao grupo B e não pode implementar passkeys nativamente, nossa recomendação se inclina para a utilização de SFAuthenticationSession / ASWebAuthenticationSession para iOS e Chrome Custom Tabs para Android (caso contrário, as passkeys não funcionarão de qualquer maneira).

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

A seguir, apresentamos as razões para esta recomendação:

5.1 Cookies e Dados Compartilhados com o Navegador#

SFAuthenticationSession / ASWebAuthenticationSession compartilham cookies e dados de sites com o Safari, proporcionando uma experiência de usuário contínua durante os processos de autenticação. O mesmo se aplica às Chrome Custom Tabs no Android.

Os usuários se beneficiam de suas senhas salvas, dados de preenchimento automático e outras informações armazenadas no navegador, tornando o processo de autenticação mais suave e rápido.

5.2 Segurança Aprimorada#

SFAuthenticationSession / ASWebAuthenticationSession no iOS e Chrome Custom Tabs no Android fornecem um espaço seguro e isolado para a autenticação do usuário, garantindo que as credenciais sensíveis do usuário sejam protegidas e não compartilhadas inadvertidamente com o aplicativo ou outros sites.

Eles aderem aos rigorosos protocolos de segurança da Apple e do Google, garantindo que os dados do usuário sejam manuseados com segurança e a privacidade seja mantida.

Além disso, essa escolha de design se beneficia das atualizações e aprimoramentos de segurança contínuos do Safari e do Chrome, garantindo que ela adira aos mais recentes padrões e protocolos de segurança.

5.3 Experiência do Usuário#

SFAuthenticationSession / ASWebAuthenticationSession no iOS e Chrome Custom Tabs no Android fornecem uma interface de usuário consistente e familiar, pois os usuários estão acostumados com a experiência do usuário do navegador. Além disso, as configurações e preferências do usuário do Safari e do Chrome são aplicadas.

Isso proporciona uma transição suave entre o conteúdo do aplicativo e o conteúdo da web, garantindo que os usuários não sejam perturbados pela mudança entre as interfaces.

5.4 Desempenho#

As Chrome Custom Tabs aproveitam o desempenho do Chrome, garantindo uma experiência de usuário suave e responsiva, o que é particularmente crucial durante os processos de autenticação para evitar a frustração ou o abandono do usuário.

O desempenho das CCT é frequentemente superior às opções de WebView do Android (o mesmo acontece com SFAuthenticationSession / ASWebAuthenticationSession no iOS), garantindo que o conteúdo da web e os fluxos de autenticação sejam tratados de forma rápida e suave.

Veja também esta comparação do Google para sentir as diferenças de desempenho entre as Chrome Custom Tabs, a Android WebView e o navegador Chrome padrão.

5.5 Dedicado para Fluxos de Autenticação#

SFAuthenticationSession / ASWebAuthenticationSession é projetado especificamente para lidar com fluxos de autenticação baseados em OAuth / OpenID Connect, garantindo um processo simplificado e seguro para esses protocolos de autenticação amplamente utilizados. É também a maneira recomendada para autenticação WebAuthn / passkey.

No Android, não há uma classe dedicada para fluxos de autenticação, mas um comportamento semelhante pode ser implementado com Chrome Custom Tabs e Android App Links.

Além disso, esperamos que mais aplicativos introduzam passkeys como o TikTok, apenas coletando-as quando o usuário está autenticado. Isso pode ser feito nativamente (implementação do TikTok) ou através de uma implementação de WebView. Uma abordagem adequada é acionar a UI Condicional nativamente. Se não funcionar, você exibe a implementação da WebView.

6. Conclusão#

No cenário moderno da autenticação digital, a implementação de passkeys via WebView em aplicativos nativos surge como um farol de prática segura e amigável ao usuário. Embora a jornada para escolher a WebView ideal possa ser complexa, é fundamental alinhar as escolhas tecnológicas com a experiência do usuário e a segurança.