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

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

Nota: As WebViews de Sistema e Incorporada são frequentemente combinadas, onde a WebView de Sistema trata do login (com partilha automática de credenciais) e, em seguida, a WebView Incorporada renderiza a gestão de passkeys nas definições.

Fatores Chave de Decisão:

• Login baseado em OAuth? → WebView do Sistema (ASWebAuthenticationSession, Chrome Custom Tabs)
• Quer reutilizar a autenticação web num shell nativo? → WebView Incorporada (WKWebView, WebView do Android com WebKit 1.12.1+)
• Está a construir uma aplicação primariamente nativa? → Implementação Nativa (Apple AuthenticationServices, Google Credential Manager)

As plataformas móveis modernas oferecem três abordagens distintas para integrar passkeys na sua aplicação nativa, cada uma com diferentes compromissos em termos de experiência do utilizador, complexidade técnica e compatibilidade com OAuth:

1. Implementação Nativa: Construa fluxos de passkeys diretamente na sua aplicação usando APIs da plataforma (AuthenticationServices do iOS, Credential Manager do Android). Proporciona a melhor experiência de utilizador com autenticação biométrica fluida, mas requer um esforço de implementação técnica médio a alto.

2. WebView do Sistema: Use o componente de browser da plataforma (ASWebAuthenticationSession / SFSafariViewController do iOS, Chrome Custom Tabs do Android) para gerir a autenticação. Excelente para fluxos de login baseados em OAuth e partilha credenciais com o browser do sistema.

3. WebView Incorporada: Incorpore uma visualização web personalizável (WKWebView do iOS, WebView do Android) dentro da sua aplicação para reutilizar a autenticação web com um esqueleto de aplicação nativa. Proporciona uma aparência semelhante à nativa, sem barras de URL, e controlo total sobre a UI da WebView. Requer configuração adicional, incluindo permissões e entitlements (iOS), e configuração da WebView com AndroidX WebKit 1.12.1+ (Android) para ativar a funcionalidade de passkeys.

A escolha certa depende da arquitetura de autenticação da sua aplicação, se usa fornecedores OAuth, quanto controlo precisa sobre a UI e se está a construir uma aplicação primariamente nativa ou a reutilizar componentes web.

Uma implementação nativa de passkeys proporciona a experiência de utilizador ideal, com fluxos de autenticação construídos diretamente na UI da sua aplicação, usando APIs específicas da plataforma. Os utilizadores beneficiam de diálogos nativos da plataforma, verificação biométrica fluida e os tempos de login mais rápidos possíveis.

Quando escolher a Implementação Nativa:

• Ao construir uma nova aplicação nativa ou a refatorar a autenticação para ecrãs nativos
• Se quiser a melhor experiência de utilizador possível com autenticação instantânea e silenciosa
• Prompts automáticos de passkey no arranque da app: As implementações nativas podem usar preferImmediatelyAvailableCredentials para exibir automaticamente um overlay de passkeys quando estas estão disponíveis, proporcionando a experiência de login mais rápida sem exigir a inserção de um identificador
• Se precisar de controlo total sobre a UI e o fluxo de autenticação
• Se estiver disposto a investir numa implementação específica da plataforma (Swift no iOS, Kotlin no Android)

Vantagem Chave: preferImmediatelyAvailableCredentials()

As implementações nativas podem tirar partido do preferImmediatelyAvailableCredentials() para criar um overlay automático de passkey que aparece imediatamente no arranque da aplicação quando existem passkeys disponíveis. Este fluxo sem nome de utilizador proporciona a experiência de login mais rápida possível — os utilizadores veem as suas passkeys instantaneamente sem primeiro inserirem um identificador. Esta capacidade é exclusiva das implementações nativas e não está disponível nas variantes com WebView.

Embora as implementações com WebView possam usar a UI Condicional (sugestões de passkey em campos de entrada), o overlay automático da implementação nativa proporciona uma UX superior com taxas de utilização de passkeys mais elevadas, uma vez que a autenticação começa imediatamente após o lançamento da aplicação.

Visão Geral dos Requisitos Técnicos:

A integração nativa de passkeys requer uma confiança criptográfica entre a sua aplicação e o domínio web. Sem ela, o sistema operativo rejeitará todas as operações WebAuthn. Requisitos chave:

1. Ficheiros de Associação Aplicação-Domínio alojados em /.well-known/
2. ID da Relying Party correto, correspondente ao seu domínio web
3. Capacidades Específicas da Plataforma (detalhadas na Secção 4)

O maior benefício: as passkeys criadas no seu site funcionam perfeitamente na sua aplicação e vice-versa.

A implementação nativa de passkeys no iOS envolve a framework AuthenticationServices da Apple, que fornece uma API para operações WebAuthn:

Componentes Chave:

• ASAuthorizationController: Gere o fluxo de autenticação
• ASAuthorizationPlatformPublicKeyCredentialProvider: Cria pedidos de passkey
• Três modos de UI distintos para gerir os logins com passkey:
  • Login em campo de texto: Campo de nome de utilizador tradicional com o login por passkey a iniciar ao submeter o botão
  • Overlay modal de passkey: Diálogo do SO que lista as passkeys disponíveis
  • UI Condicional: Sugestões de passkey na barra QuickType acima do teclado

Dicas de Desenvolvimento

• Caching do AASA: A Apple armazena em cache o ficheiro AASA de forma agressiva (até 24 horas), o que pode frustrar os testes. Solução: Ative o Modo de Programador no seu dispositivo de teste e anexe ?mode=developer ao URL do seu AASA para forçar novas obtenções.
• Testes de Desempenho: Teste com contas iCloud que contenham centenas de credenciais para observar a latência no mundo real. O overlay do sistema pode apresentar um ligeiro atraso com muitas passkeys armazenadas.

A implementação nativa de passkeys do Android utiliza a API Credential Manager (ou a API mais antiga FIDO2 para retrocompatibilidade):

Componentes Chave:

• CredentialManager: API central para todas as operações de credenciais
• CreatePublicKeyCredentialRequest: Para registo de passkeys
• GetCredentialRequest: Para autenticação com passkey
• Dois modos de UI principais:
  • Login em campo de texto: Campo de nome de utilizador tradicional com o login por passkey a iniciar ao submeter o botão
  • Overlay modal de passkey: Diálogo do SO que lista as passkeys disponíveis

Nota: Atualmente, o Android não possui as sugestões de teclado da UI Condicional do iOS em aplicações nativas (embora a UI Condicional funcione em aplicações web).

A implementação nativa de passkeys apresenta desafios e lições importantes: a integração ao nível do sistema operativo pode revelar problemas em diferentes dispositivos e versões do SO.

1. Por exemplo, a nossa equipa encontrou problemas como o caching agressivo da Apple do ficheiro apple-app-site-association (usado para ligar credenciais de aplicação/web) e diferenças subtis de UI em alguns prompts biométricos de certos OEMs do Android.
2. Além disso, considere que, em alguns cenários empresariais, os dispositivos geridos podem ter a sincronização de passkeys desativada por política. Em ambientes corporativos onde a sincronização do Chaves do iCloud ou do Gerenciador de Senhas do Google está desligada, as passkeys tornam-se vinculadas ao dispositivo e não serão partilhadas — um cenário importante a planear (por exemplo, garantir que os utilizadores ainda possam fazer login se tiverem um novo telemóvel).
3. Adicionalmente, aplicações de gestão de credenciais de terceiros podem influenciar o fluxo. Por exemplo, se um utilizador tiver um gestor de palavras-passe como o 1Password definido como um fornecedor de credenciais ativo, este irá frequentemente intercetar a criação e o armazenamento de passkeys, tendo prioridade sobre o gestor de credenciais nativo da plataforma.

Embora seja possível implementar passkeys usando as APIs nativas da plataforma, SDKs especializados aceleram significativamente o desenvolvimento ao lidar com a complexidade do WebAuthn, casos de exceção e ao fornecer telemetria integrada. Os SDKs também oferecem interfaces simuláveis para testes unitários (crucial, uma vez que não se pode testar biometria em simuladores).

Recomendação: Para implementações nativas, recomendamos o uso dos SDKs da Corbado (SDK de Passkey para iOS em Swift, SDK de Passkey para Android em Kotlin), que lidam com os inúmeros casos de exceção descobertos através de implementações em produção, fornecem telemetria e testes adicionais.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.

Passkeys que milhões adotam, rapidamente. Comece com a Plataforma de Adoção da Corbado.

Comece o Teste Gratuito

As WebViews do Sistema usam o componente de browser nativo da plataforma para gerir a autenticação dentro da sua aplicação. Ao contrário das implementações totalmente nativas, as WebViews do Sistema exibem conteúdo web usando o próprio browser do sistema (Safari no iOS, Chrome no Android), mantendo cookies partilhados, credenciais guardadas e os indicadores de segurança familiares do browser.

Quando escolher a WebView do Sistema:

• A sua aplicação usa login baseado em OAuth: A WebView do Sistema é a abordagem recomendada para fluxos OAuth2/OIDC, proporcionando autenticação segura.
• Autenticação existente baseada na web que pretende reutilizar em aplicações móveis.
• Necessidade de suportar múltiplos métodos de autenticação (palavras-passe, login social, passkeys) sem reconstruir nativamente.
• Desejo de manter uma única base de código de autenticação para a web e o telemóvel.

Vantagens Chave:

• Compatibilidade com OAuth: Criado propositadamente para fluxos de autenticação OAuth/OIDC.
• Indicadores de segurança: Os utilizadores veem o URL real e os certificados SSL, construindo confiança.
• Baixo esforço de implementação: Requer código nativo mínimo.
• UX consistente: Interface de browser familiar em que os utilizadores já confiam.

Componentes da Plataforma:

• iOS: ASWebAuthenticationSession (recomendado para fluxos de autenticação) ou SFSafariViewController (navegação geral).
• Android: Chrome Custom Tabs (CCT).

Grandes empresas como a Google e o GitHub adotaram esta abordagem para adicionar o login com passkey às suas aplicações móveis através de overlays de WebView sobre as páginas de autenticação web existentes. Isto funciona bem quando a reconstrução de uma autenticação totalmente nativa não é imediatamente viável.

O iOS fornece dois componentes principais de WebView do Sistema para autenticação:

ASWebAuthenticationSession (Recomendado para Autenticação):

• Criado propositadamente para fluxos OAuth/OIDC e de login seguro.
• Avisa automaticamente o utilizador que a aplicação quer autenticar-se.
• Partilha cookies e credenciais com o Safari.
• Suporta passkeys através do Chaves do iCloud.

SFSafariViewController (Navegação Geral):

• Experiência Safari completa dentro da aplicação.
• Mostra a barra de URL e indicadores de segurança.
• Não partilha cookies do Safari no iOS 11+; use ASWebAuthenticationSession quando for necessária a partilha de sessão do Safari.
• Menos personalizável, mas mais confiável para os utilizadores.

Se a sua aplicação usa login baseado em OAuth, ASWebAuthenticationSession é a escolha recomendada, pois foi especificamente desenhado para cenários de autenticação e oferece o melhor equilíbrio entre segurança e experiência do utilizador.

Os Chrome Custom Tabs (CCT) proporcionam uma experiência de autenticação baseada no Chrome dentro da sua aplicação:

Funcionalidades Chave:

• Partilha cookies e credenciais com o browser Chrome.
• Mostra o URL e indicadores de segurança.
• Pode personalizar a cor da barra de ferramentas e a marca.
• Pré-aquecimento para tempos de carregamento mais rápidos.

Integração OAuth: Os Chrome Custom Tabs são o equivalente no Android ao ASWebAuthenticationSession do iOS, proporcionando um excelente suporte a OAuth enquanto mantêm o acesso a passkeys armazenadas.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

As WebViews Incorporadas proporcionam controlo total sobre a renderização do conteúdo web dentro da sua aplicação, permitindo a manipulação direta de cookies, sessões e navegação sem a barra de URL. No entanto, este controlo vem com requisitos técnicos adicionais para ativar a funcionalidade de passkeys.

Quando escolher a WebView Incorporada:

• Experiência semelhante à nativa: A sua aplicação já incorpora a autenticação numa WebView personalizada para manter uma aparência nativa, e quer manter essa experiência de utilizador consistente.
• Necessidade de controlo de sessão/cookie: A sua aplicação requer a manipulação direta de tokens de autenticação e estado da sessão após a conclusão da autenticação OAuth.
• Fluxo de autenticação existente onde a autenticação da WebView do Sistema devolve um código de autorização, mas não uma sessão em contextos incorporados.
• Necessidade de manter o estado autenticado em múltiplos ecrãs web incorporados.
• Apenas autenticação de primeira parte: A sua aplicação gere a autenticação diretamente. Para implementações de passkey de terceiros, veja aqui.
• AndroidX WebKit 1.12.1+ com deteção de funcionalidades em tempo de execução.
• Aceitar a limitação da UI Condicional para Login (não suportada em WebView Incorporada), não relevante para as definições de gestão.

Contexto Importante:

Muitas aplicações usam uma abordagem híbrida: a WebView do Sistema gere a autenticação OAuth inicial (onde as passkeys funcionam perfeitamente), e depois mudam para a WebView Incorporada para o pós-autenticação, a fim de gerir as passkeys nas definições. Os desafios surgem ao tentar usar passkeys diretamente dentro de WebViews Incorporadas.

Requisitos Técnicos:

As WebViews Incorporadas requerem configuração adicional em comparação com as WebViews do Sistema:

1. iOS: Entitlements de Domínios Associados, configuração do ficheiro AASA.
2. Android: AndroidX WebKit 1.12.1+ com configuração de WebAuthn na WebView (deteção de funcionalidades necessária).
3. Ambos: Ficheiros de associação well-known configurados corretamente e Digital Asset Links.

Componentes da Plataforma:

• iOS: WKWebView
• Android: android.webkit.WebView

Compromissos:

• Complexidade média: Requer configuração da WebView (Android WebKit 1.12.1+) e configuração de entitlements (iOS).
• Menor adoção de passkeys: Os utilizadores podem encontrar mais atrito em comparação com a implementação nativa.
• UI Condicional não suportada: O preenchimento automático de passkey em campos de entrada não funciona em WebViews Incorporadas no Android.
• Suporte limitado da plataforma: Algumas funcionalidades podem não funcionar de forma consistente (ex: criação automática de passkey).

Ao implementar passkeys através de WebViews, é crucial entender a distinção entre WebViews de Sistema e WebViews Incorporadas. As três abordagens descritas acima (Implementação Nativa, WebView de Sistema e WebView Incorporada) servem casos de uso diferentes.

No iOS, tem múltiplas opções para exibir conteúdo web na aplicação:

• WKWebView é uma WebView personalizável que faz parte da framework WebKit (introduzida no iOS 8). Dá-lhe muito controlo sobre a aparência e o comportamento do conteúdo web.
• SFSafariViewController é um view controller fornecido pela Apple que atua como um browser Safari leve dentro da sua aplicação. Utiliza o motor do Safari. No iOS 11+, tem um armazenamento de cookies separado e não partilha cookies do Safari. Use ASWebAuthenticationSession quando a partilha de sessão do Safari for necessária.
• SFAuthenticationSession / ASWebAuthenticationSession são sessões de autenticação web especializadas (disponíveis desde o iOS 11/12) destinadas especificamente a fluxos OAuth/OpenID ou outros fluxos de login seguros. Estas também aproveitam o Safari nos bastidores, mas focam-se em fluxos de autenticação e gerem automaticamente coisas como cookies partilhados e Single Sign-On (SSO).

No Android, as principais escolhas são:

• Android WebView é o widget padrão de WebView (android.webkit.WebView), que é essencialmente um mini browser que pode ser incorporado nas suas atividades. É altamente personalizável, mas corre no processo da sua aplicação.
• Chrome Custom Tabs (CCT) é uma funcionalidade que abre um separador baseado no Chrome dentro do contexto da sua aplicação. Os Custom Tabs aparecem como parte da sua aplicação, mas são alimentados pelo browser Chrome (se instalado), com funcionalidades como pré-carregamento, cookies partilhados e a familiar barra de URL para a confiança do utilizador.

Nas secções seguintes, vamos aprofundar um pouco mais estes tipos de WebView para iOS e Android, e discutir qual pode ser o mais adequado para fluxos de autenticação com passkeys.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

A plataforma da Apple fornece as três opções de WebView listadas acima. A sua escolha afetará a fluidez com que as passkeys podem ser usadas dentro da aplicação:

Para testar o comportamento das diferentes WebViews no iOS, recomendamos a aplicação WebView - WKWebView and UIWebView rendering.

WKWebView é um componente de WebView versátil para iOS. Os programadores podem incorporar uma WKWebView para renderizar conteúdo web com um alto grau de controlo sobre a UI e o comportamento. A WKWebView utiliza o mesmo motor de renderização do Safari, pelo que é muito performante e suporta funcionalidades web modernas. Em teoria, a WKWebView pode lidar com WebAuthn (e, portanto, passkeys) se configurada corretamente, mas note que algumas funcionalidades avançadas do browser podem ser restringidas por segurança. Uma coisa a ter em atenção é que a WKWebView, por defeito, não partilha cookies ou dados do keychain com o Safari Mobile. Os utilizadores podem ter de fazer login novamente porque a sua sessão na WebView está isolada da sessão do Safari. Além disso, como o conteúdo da WKWebView pode ser totalmente personalizado pela aplicação, o utilizador não vê uma barra de endereço ou a UI do Safari – o que é ótimo para a marca, mas significa que o utilizador tem menos pistas para verificar a legitimidade da página (uma preocupação para anti-phishing). Algumas aplicações até abusaram da WKWebView para injetar scripts ou alterar conteúdo (por exemplo, foi notado que o TikTok injetava JS de rastreamento através do seu browser na aplicação), pelo que se deve ter cuidado ao usar a WKWebView de uma forma segura e que inspire confiança no utilizador.

SFSafariViewController proporciona uma experiência Safari dentro da aplicação. Quando abre um URL com o SFSafariViewController, é quase como abri-lo no browser Safari real, exceto que o utilizador permanece dentro da UI da sua aplicação. A vantagem para as passkeys é significativa: como é essencialmente o Safari, o Chaves do iCloud do utilizador e as passkeys guardadas estão acessíveis. Note que os cookies não são partilhados no iOS 11+. Isto significa que, se o utilizador já tiver uma passkey para o seu site, o Safari pode encontrá-la e até exibir o preenchimento automático da UI Condicional para um login fácil. O SFSafariViewController é menos personalizável (não pode alterar muito a sua barra de ferramentas), mas trata automaticamente de muitas funcionalidades de segurança e privacidade. A barra de URL é mostrada, completa com o ícone do cadeado para HTTPS, o que dá aos utilizadores a confiança de que estão no domínio correto. Em geral, o SFSafariViewController é considerado mais seguro do que uma WKWebView pura e é mais simples de implementar (a Apple fornece-o como um componente pronto a usar). O principal compromisso é que sacrifica algum controlo sobre a aparência e o comportamento. Para um fluxo de autenticação, isso é geralmente aceitável. A prioridade aqui é a segurança e a facilidade de login, nas quais o SFSafariViewController se destaca ao usar o contexto do Safari.

SFAuthenticationSession / ASWebAuthenticationSession – Estas classes (sendo a última o nome mais recente e amigável para Swift) são construídas especificamente para fluxos de login como OAuth ou OpenID Connect. Quando precisa de autenticar um utilizador através de uma página web (talvez para um IdP externo), estas sessões são a escolha recomendada no iOS. São muito semelhantes ao SFSafariViewController, na medida em que utilizam o browser Safari nos bastidores e partilham cookies/armazenamento com o Safari. A principal diferença é que a SFAuthenticationSession irá sempre avisar o utilizador de que a aplicação quer autenticar-se usando uma página web (para consciencialização do utilizador) e irá usar automaticamente a sessão existente do utilizador no Safari, se disponível.

O benefício é uma experiência de SSO fluida – se o utilizador já estiver com login feito no fornecedor no Safari, esta sessão pode usar esse cookie para evitar outro login. Para passkeys, isto é importante porque significa que qualquer credencial de passkey armazenada no Safari/Chaves do iCloud também pode ser usada aqui. A orientação oficial da Apple é usar a ASWebAuthenticationSession para tudo o que se assemelhe a um fluxo de login. Os prós são a privacidade melhorada (a sua aplicação nunca vê as credenciais ou cookies, o Safari trata disso) e o suporte integrado a SSO. O contra é que está limitado a fluxos de autenticação (não o usaria para apenas renderizar conteúdo web arbitrário na sua aplicação). Em resumo, se escolher uma abordagem de WebView no iOS, a ASWebAuthenticationSession é tipicamente a melhor escolha para implementar passkeys porque é segura, partilha o estado com o Safari e foi construída propositadamente para autenticação.

Want to find out how many people use passkeys?

View Adoption Data

No Android, a decisão sobre a WebView é entre a WebView clássica e os Chrome Custom Tabs:

Para testar o comportamento das diferentes WebViews no Android, recomendamos a aplicação WebView vs Chrome Custom Tabs.

Android WebView (android.webkit.WebView) é um componente que lhe permite incorporar páginas web no layout da sua atividade. É semelhante à WKWebView na medida em que lhe dá controlo total: pode intercetar a navegação, injetar JavaScript, personalizar a UI, etc. Também corre dentro do processo da sua aplicação. Usar uma WebView para passkeys significa que a sua aplicação carrega a sua página de login web, e essa página pode iniciar uma cerimónia de passkey WebAuthn. A Android WebView moderna suporta WebAuthn (desde que a implementação da WebView do dispositivo esteja atualizada através da Android System WebView ou do componente Chrome). Uma grande consideração: por defeito, uma Android WebView não partilha cookies ou credenciais armazenadas com o browser Chrome do utilizador. Assim, qualquer passkey criada ou usada na WebView pode não ser conhecida pelo Chrome, e vice-versa. Este isolamento pode ser bom para a segurança (a sua aplicação não pode ler os cookies do browser), mas pode forçar os utilizadores a fazer login novamente se já se tiverem autenticado no Chrome. Outra questão é a confiança. Uma WebView simples não mostra o URL ou o ícone do cadeado SSL, pelo que os utilizadores têm de confiar completamente na sua aplicação para não serem alvo de phishing. A Google até proibiu o uso da WebView para logins OAuth da Google devido a potenciais riscos de phishing. Em termos de desempenho, as WebViews são aceitáveis, mas podem ser mais lentas ou mais intensivas em memória do que usar o browser padrão do utilizador, especialmente se carregarem páginas pesadas.

Chrome Custom Tabs (CCT) são uma abordagem híbrida. Permitem que a sua aplicação abra uma página renderizada pelo Chrome que parece fazer parte da sua aplicação. Pode personalizar a cor da barra de ferramentas, adicionar um logótipo da aplicação, etc., mas o conteúdo é renderizado pelo Chrome num processo separado. Para passkeys, os CCTs têm vários benefícios: partilham os cookies e credenciais do utilizador com o Chrome, o que significa que se o utilizador tiver uma passkey guardada através do Chrome (Gerenciador de Senhas do Google), o Custom Tab pode aceder a ela. O utilizador também verá o URL real e os indicadores de segurança, o que gera confiança. O desempenho é muitas vezes melhor – o Chrome pode ser "aquecido" em segundo plano para um carregamento mais rápido. E, importante, a segurança é forte: como é essencialmente a aplicação Chrome, coisas como o Google Safe Browsing protegem a sessão, e a sua aplicação não pode injetar scripts arbitrários na página (prevenindo certos ataques).

A desvantagem é que requer que o utilizador tenha o Chrome (ou um browser suportado) instalado e atualizado. A maioria dos utilizadores de Android tem, mas em alguns dispositivos em certas regiões, isto pode ser um problema. No geral, se optar por uma abordagem web incorporada no Android, os Chrome Custom Tabs são recomendados para fluxos de passkey, pois proporcionam um bom equilíbrio entre integração e segurança. Na verdade, são análogos ao SFSafariViewController/ASWebAuthSession do iOS de muitas formas – aproveitando o browser padrão para autenticação.

(Apartado: A WKWebView vs SFSafariViewController da Apple e a WebView vs CCT do Android têm muitos paralelos. Tanto o Safari VC como os Chrome Tabs partilham o estado do browser e proporcionam melhor segurança, enquanto a WKWebView/Android WebView dão mais controlo, mas isolam o conteúdo web. Para passkeys, a partilha de estado (cookies, armazenamentos de credenciais) é geralmente desejável para que a passkey possa ser acedida e criada de forma fluida.)

Independentemente da abordagem de implementação que escolher, certos requisitos técnicos devem ser cumpridos para ativar a funcionalidade de passkeys. Esta secção fornece orientação abrangente sobre a configuração de ficheiros de associação well-known, entitlements do iOS e configuração da WebView do Android.

Nota sobre Dispositivos Geridos: O comportamento das passkeys muda significativamente em dispositivos geridos onde as políticas de Gestão de Dispositivos Móveis (MDM) controlam o armazenamento de credenciais. Para testar passkeys em dispositivos geridos, consulte Passkeys em Dispositivos Geridos iOS & Android.

Os fluxos Nativo e de WebView Incorporada requerem ficheiros de associação para estabelecer confiança criptográfica entre a sua aplicação e o domínio web. A WebView de Sistema (ASWebAuthenticationSession) e os Chrome Custom Tabs não requerem associação da aplicação ao site.

O ficheiro AASA estabelece a ligação entre a sua aplicação iOS e o seu domínio web, permitindo que as passkeys funcionem em ambas as plataformas.

Localização do Ficheiro: https://oseudominio.com/.well-known/apple-app-site-association

Requisitos de Configuração:

• Alojar em /.well-known/apple-app-site-association no seu domínio
• Servir sobre HTTPS com um certificado SSL válido
• Content-Type: application/json
• Sem redirecionamentos no caminho .well-known
• Incluir o Team ID e o Bundle ID da sua aplicação

Exemplo de Ficheiro AASA:

{
    "webcredentials": {
        "apps": ["TEAMID123.com.example.app"]
    }
}

Caching e Teste do AASA:

A Apple armazena agressivamente em cache os ficheiros AASA (até 24-48 horas) usando uma CDN, o que pode frustrar o desenvolvimento e os testes. Para contornar o cache durante o desenvolvimento:

1. Ative o Modo de Programador no seu dispositivo de teste
2. Anexe ?mode=developer ao seu domínio associado no Xcode
3. Isto força o iOS a obter o ficheiro AASA mais recente diretamente do seu servidor

⚠️ Importante: NÃO use ?mode=developer em versões de produção. Este parâmetro é apenas para desenvolvimento — usá-lo em produção impedirá o iOS de detetar corretamente o seu ficheiro AASA, quebrando a funcionalidade de passkeys.

Validação: Use o Validador AASA da Apple para verificar a sua configuração.

O Android usa Digital Asset Links para verificar a relação entre a sua aplicação e o seu site.

Localização do Ficheiro: https://oseudominio.com/.well-known/assetlinks.json

Requisitos de Configuração:

• Alojar em /.well-known/assetlinks.json no seu domínio
• Servir sobre HTTPS com um certificado válido
• Content-Type: application/json
• Incluir a impressão digital SHA256 da sua aplicação (do certificado de assinatura)

Exemplo de Ficheiro assetlinks.json:

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.example.app",
            "sha256_cert_fingerprints": [
                "AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99"
            ]
        }
    }
]

Validação: Use o Gerador de Digital Asset Links da Google para criar e verificar a sua configuração.

As aplicações iOS requerem entitlements adequados para aceder à funcionalidade de passkeys. Os requisitos diferem ligeiramente com base na sua abordagem de implementação.

O ficheiro de entitlements (muitas vezes chamado Runner.entitlements em aplicações Flutter ou ASuaApp.entitlements em projetos nativos iOS) define permissões e capacidades especiais concedidas pelo sistema da Apple. Para passkeys, este ficheiro configura os Domínios Associados.

Localização do Ficheiro: Tipicamente no seu projeto Xcode em ios/Runner/Runner.entitlements

A Implementação Nativa e a WebView Incorporada requerem a capacidade de Domínios Associados para ligar a sua aplicação ao seu domínio web. A WebView de Sistema (ASWebAuthenticationSession) não requer isto, pois corre no contexto do Safari.

Configuração no Xcode:

1. Abra o seu projeto no Xcode
2. Selecione o seu target da aplicação
3. Vá ao separador "Signing & Capabilities"
4. Clique em "+ Capability" e adicione "Associated Domains"
5. Adicione o seu domínio com o prefixo webcredentials:

Exemplo de Configuração:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.developer.associated-domains</key>
    <array>
        <string>webcredentials:oseudominio.com</string>
        <string>webcredentials:subdominio.oseudominio.com</string>
    </array>
</dict>
</plist>

Múltiplos Domínios: Se a sua aplicação precisar de funcionar com múltiplos domínios, pode precisar de Related Origin Requests (ROR).

As WebViews Incorporadas do Android ganharam suporte nativo a WebAuthn com o AndroidX WebKit 1.12, eliminando a necessidade de código de ponte JavaScript personalizado. A WebView de Sistema (Chrome Custom Tabs) não requer qualquer configuração — as credenciais funcionam automaticamente.

Requisitos:

• AndroidX WebKit 1.12.1 ou mais recente (1.14.0+ recomendado)
• Digital Asset Links configurados
• APK da WebView com suporte a WebAuthn (verificar através de deteção de funcionalidades)
• Nota: A biblioteca AndroidX Credentials NÃO é necessária para WebAuthn em WebView, apenas para implementações totalmente nativas

Implementação:

import androidx.webkit.WebSettingsCompat
import androidx.webkit.WebViewFeature
 
// Verificar se a Autenticação Web é suportada
if (WebViewFeature.isFeatureSupported(WebViewFeature.WEB_AUTHENTICATION)) {
    // Ativar a Autenticação Web
    WebSettingsCompat.setWebAuthenticationSupport(
        webView.settings,
        WebSettingsCompat.WEB_AUTHENTICATION_SUPPORT_FOR_APP
    )
 
    // Ativar JavaScript
    webView.settings.javaScriptEnabled = true
}

Pontos Chave:

• Não é necessária ponte JavaScript: O WebAuthn funciona nativamente na WebView
• Deteção de funcionalidades necessária: Verifique sempre WebViewFeature.WEB_AUTHENTICATION em tempo de execução
• UI Condicional não suportada: mediation:"conditional" (preenchimento automático de passkeys em campos de entrada) não funciona na WebView Incorporada
• Estratégia de fallback: Se a funcionalidade não estiver disponível, use os Chrome Custom Tabs em vez disso

Notas de Versão:

• Use o WebKit 1.12.1 ou mais recente (o 1.12.0 tinha um problema de disponibilidade em tempo de execução)
• O suporte da funcionalidade depende da versão do APK da WebView do utilizador — APKs mais antigos no dispositivo não irão expor a funcionalidade

Antes do AndroidX WebKit 1.12.0, não existia suporte nativo a WebAuthn na WebView Incorporada. As equipas tinham de:

1. Usar Chrome Custom Tabs ou Auth Tab (recomendado)
2. Construir uma ponte JavaScript personalizada

Se precisar de suportar versões mais antigas do Android ou dispositivos sem APKs da WebView atualizados, consulte o guia de Integração da WebView do Credential Manager do Android para a abordagem de código de ponte. No entanto, recomendamos vivamente o uso da abordagem nativa do WebKit 1.12.1+ para aplicações modernas.

Recomendação: Use o suporte nativo a WebAuthn com o AndroidX WebKit 1.12.1+. Se não estiver disponível em tempo de execução, recorra aos Chrome Custom Tabs, que fornecem excelente suporte a passkeys com credenciais partilhadas.

Ao implementar passkeys em aplicações nativas, precisa de estabelecer confiança entre a sua aplicação e o(s) seu(s) domínio(s) web. Esta secção cobre como lidar com domínios únicos, múltiplos domínios relacionados (ROR) e como verificar se os seus ficheiros de associação well-known estão configurados corretamente.

Para aplicações que usam um único domínio (ex: kayak.com), precisa de:

• Um ficheiro AASA para iOS em https://kayak.com/.well-known/apple-app-site-association
• Um assetlinks.json para Android em https://kayak.com/.well-known/assetlinks.json
• Entitlement de Domínios Associados configurado com webcredentials:kayak.com

Origens Relacionadas (ROR) é uma funcionalidade do WebAuthn que permite que um único conjunto de passkeys funcione em múltiplos domínios relacionados (ex: kayak.com, kayak.de, kayak.co.uk). O ROR usa o endpoint /.well-known/webauthn em cada site para definir origens relacionadas, NÃO os ficheiros AASA ou assetlinks.

Pontos Chave:

• Configuração de ROR: Cada domínio aloja /.well-known/webauthn com a lista de origens relacionadas
• Ficheiros de associação da aplicação (AASA/assetlinks): Usados apenas para mapear aplicações aos seus sites correspondentes
• WebView Incorporada no iOS 18+: Suporta ROR quando configurado corretamente
• Entitlements de Domínios Associados: Inclua todos os domínios com os quais a sua aplicação precisa de se autenticar

Exemplo de Configuração:

Se a sua aplicação funciona com kayak.com e kayak.de, ambos os domínios devem:

• Alojar os seus respetivos ficheiros AASA com o mesmo Team ID e Bundle ID
• Estar listados nos entitlements de Domínios Associados da sua aplicação
• Ter ficheiros well-known configurados corretamente e acessíveis

Antes de entrar em produção, verifique se os seus ficheiros well-known estão configurados corretamente e acessíveis. A Apple e a Google fornecem URLs de teste baseados em CDN para verificar a disponibilidade dos ficheiros:

Usando Estes URLs de Teste:

• Clique nos links para verificar se a Apple/Google conseguem obter os seus ficheiros well-known
• O parâmetro ?nocache=1 da Apple força uma nova obtenção, contornando o cache da CDN
• Se os ficheiros não estiverem acessíveis através destes URLs, a funcionalidade de passkeys não funcionará na sua aplicação
• Substitua kayak.com ou kayak.de pelo(s) seu(s) próprio(s) domínio(s) nos padrões de URL acima

Armadilha de Teste: Garanta que todos os domínios têm ficheiros well-known configurados corretamente. Um ficheiro em falta ou mal configurado em qualquer domínio pode quebrar a funcionalidade de passkeys para esse domínio.

Mais Informação: ID da Relying Party do WebAuthn em Aplicações Nativas

Escolher a abordagem de implementação correta depende da arquitetura de autenticação da sua aplicação, dos requisitos de OAuth e da necessidade de controlo de sessão. Use esta árvore de decisão para determinar o melhor caminho a seguir.

Comece com estas questões chave:

1. A sua aplicação usa login baseado em OAuth (OAuth2, OIDC, fornecedores de login social)?

   • Sim → WebView de Sistema (Secção 1.2)
     • iOS: Use ASWebAuthenticationSession
     • Android: Use Chrome Custom Tabs
     • Excelente suporte a OAuth com credenciais partilhadas

2. Quer reutilizar a autenticação web num shell com aspeto nativo (sem barra de URL, controlo total da UI)?

   • Sim → WebView Incorporada (Secção 1.3) com configuração
   • iOS: WKWebView + entitlements de Domínios Associados
   • Android: WebView + configuração do AndroidX WebKit 1.12.1+
   • Proporciona uma aparência semelhante à nativa enquanto reutiliza componentes web
   • Nota: A UI Condicional não é suportada na WebView Incorporada
   • Não → Considere a WebView de Sistema ou Nativa

3. Está a construir uma nova aplicação nativa ou tem ecrãs de login nativos?

   • Sim → Implementação Nativa (Secção 1.1)
     • Melhor experiência do utilizador
     • Autenticação instantânea e silenciosa
     • Requer desenvolvimento específico da plataforma

4. Já tem uma autenticação web que quer reutilizar?

   • Sim → WebView de Sistema para uma implementação rápida
   • Não → Implementação Nativa para uma UX ótima

Eis como cada abordagem se comporta em dimensões chave:

Explicação das Dimensões:

• Criar Passkeys: Quão facilmente os utilizadores podem criar passkeys através desta abordagem
• Usar Passkeys: A experiência de autenticação ao usar passkeys existentes
• Gerir Passkeys: Como os utilizadores veem, editam ou eliminam passkeys
• Complexidade Técnica: Esforço de desenvolvimento e manutenção contínua
• Suporte OAuth: Quão bem a abordagem lida com fluxos de autenticação OAuth2/OIDC
• Tempo de Configuração: Linha de tempo de implementação típica

Recomendado: WebView de Sistema

Se a sua aplicação se autentica via OAuth2, OIDC ou fornecedores de login social (Google, GitHub, Microsoft, etc.), a WebView de Sistema é a escolha ótima:

• iOS: ASWebAuthenticationSession é construído propositadamente para fluxos OAuth
• Android: Os Chrome Custom Tabs proporcionam uma integração OAuth fluida
• Benefícios: Código nativo mínimo, partilha automática de credenciais
• Implementação: Adicione WebAuthn à sua página de autenticação web e depois carregue-a através da WebView de Sistema

Exemplo: Aplicações de Viagens como kayak.com e kayak.de usam OAuth para autenticação. A WebView de Sistema permite-lhes manter a sua infraestrutura OAuth existente enquanto adicionam suporte a passkeys através das suas páginas de autenticação web.

Recomendado: Abordagem Híbrida

Use a WebView de Sistema para a autenticação OAuth inicial e, em seguida, a WebView Incorporada para sessões pós-autenticação:

1. Autenticação Inicial: A WebView de Sistema lida com o login OAuth + passkey
2. Gestão de Sessão: Mude para a WebView Incorporada para conteúdo web autenticado onde precisa de controlo de cookies/sessão
3. Configuração Técnica: Configure os requisitos tanto da WebView de Sistema como da Incorporada — para Android, garanta que o AndroidX WebKit 1.12.1+ está incluído (ver Secção 5)

Quando usar: Aplicações que se autenticam via OAuth mas que depois precisam de exibir conteúdo web autenticado onde é necessária a manipulação direta da sessão.

Recomendado: Implementação Nativa

Se está a construir de raiz ou tem ecrãs nativos? Opte por uma implementação totalmente nativa:

• iOS: Use a framework AuthenticationServices
• Android: Use a API Credential Manager
• Benefícios: Melhor UX, autenticação instantânea, controlo total
• Vantagem Única: Use preferImmediatelyAvailableCredentials para exibir um overlay automático de passkey no arranque da aplicação - exclusivo para implementações nativas e que proporciona as mais altas taxas de conversão
• Recomendação de SDK: Use os SDKs da Corbado (iOS, Android) para acelerar o desenvolvimento com tratamento de casos de exceção testado em produção

Para Novas Aplicações: Recomendo vivamente construir um login nativo desde o primeiro dia. Prepara-o para uma UX ótima e evita futuras migrações de WebView para nativo.

Recomendado: Migração Faseada

• Fase 1: Passkeys com WebView de Sistema - Adicione suporte a passkeys ao login web existente, carregue-o via WebView de Sistema (ASWebAuthenticationSession/Chrome Custom Tabs). Uma vitória rápida com código nativo mínimo.
• Fase 2: Interceção Nativa - Adicione uma verificação nativa de passkey antes de mostrar a WebView. Exemplo: kayak.com tenta primeiro a autenticação nativa com passkey e recorre à WebView se necessário. Proporciona um login biométrico rápido enquanto mantém a retrocompatibilidade.
• Fase 3: Totalmente Nativo - Migre gradualmente para a autenticação nativa para utilizadores de passkey, mantendo a WebView para métodos legados.

Esta abordagem faseada permite melhorias incrementais sem perturbar os utilizadores existentes.

Consulte a Secção 5 para instruções detalhadas de configuração.

Testar passkeys em aplicações nativas requer uma abordagem estruturada e multi-camadas. Siga a pirâmide de testes: testes unitários (lógica isolada), testes de integração (cerimónia WebAuthn em simuladores/emuladores) e testes de sistema (ponta a ponta em dispositivos físicos).

Categorias de Teste Essenciais:

• Jornadas Principais: Registo, autenticação, fluxos entre dispositivos, eliminação de passkey
• Cobertura da Plataforma: iOS (nativo), Android (nativo), browsers web em várias versões de SO
• Associação de Domínio: Verificar se os ficheiros AASA (iOS) e os Digital Asset Links (Android) estão acessíveis
• Fluxos de Cancelamento: Testar o cancelamento do utilizador nos prompts do SO e nos ecrãs biométricos
• Tratamento de Erros: Falhas de backend, timeouts de rede, incompatibilidades de credenciais
• Casos de Exceção: Bloqueio de ecrã desativado, Chaves do iCloud/Gerenciador de Senhas do Google desativado
• Fluxos OAuth: Integração completa de OAuth + passkey de ponta a ponta
• Dispositivos Geridos: Ambientes controlados por MDM (ver teste de dispositivos geridos)
• Gestores de Terceiros: Compatibilidade com 1Password, Bitwarden, Dashlane
• Autenticação entre Dispositivos: Fluxos de código QR e teste de transporte híbrido
• Específico da WebView Incorporada: Se usar a WebView Incorporada, verifique a configuração do WebKit 1.12.1+ no Android
• Monitorização em Produção: Dashboard para taxas de sucesso, falhas e latência

Para orientação de testes abrangente, incluindo estratégias de automação, particularidades específicas da plataforma e uma lista de verificação pré-lançamento completa, consulte o nosso guia dedicado: Testar Fluxos de Passkey em Aplicações Nativas iOS & Android.

Considere pedir aos utilizadores para criarem passkeys após um login tradicional bem-sucedido (palavra-passe, OAuth). Esta abordagem de conversão gradual:

• Não perturba os fluxos de autenticação existentes
• Permite uma degradação graciosa se o utilizador recusar
• Aumenta a adoção de passkeys ao longo do tempo sem forçar mudanças
• Funciona bem com todas as três abordagens de implementação

Exemplo: Após o login OAuth via WebView de Sistema, mostre um prompt nativo: "Ativar login mais rápido com Face ID?" Se aceite, crie a passkey através da página web carregada na WebView de Sistema.

Decidir como implementar passkeys — através de Implementação Nativa, WebView de Sistema ou WebView Incorporada — é uma escolha de design crucial que impacta a segurança, a experiência do utilizador e a complexidade do desenvolvimento. Não há uma resposta única para todos.

Para aplicações baseadas em OAuth: A WebView de Sistema (ASWebAuthenticationSession, Chrome Custom Tabs) é o ponto de partida recomendado. Fornece um excelente suporte a OAuth, esforço de implementação mínimo e partilha automática de credenciais.

Para aplicações focadas no nativo: Opte pelo nativo mais cedo ou mais tarde. Um login com passkey nativo oferece a UX mais fluida com capacidades exclusivas como preferImmediatelyAvailableCredentials, que ativa um overlay automático de passkey no arranque da aplicação — algo que as implementações com WebView não podem fornecer. Com o iOS e o Android a oferecerem agora suporte de primeira classe para passkeys, os sucessos do mundo real demonstram uma alta adoção. As ferramentas (incluindo SDKs de código aberto e bibliotecas de plataforma) amadureceram para tornar a integração nativa alcançável em prazos razoáveis. Embora deva estar atento às políticas de gestão de dispositivos, sincronização entre dispositivos e fornecedores de terceiros, estes desafios podem ser geridos com engenharia e testes cuidadosos. O resultado é um login de aplicação que encanta os utilizadores com a sua facilidade e velocidade, enquanto melhora significativamente a segurança.

Para requisitos de frames de WebView incorporada: A WebView Incorporada é comummente usada em dois cenários do mundo real. Primeiro, as aplicações baseadas em OAuth usam frequentemente a WebView de Sistema para o fluxo de login inicial, e depois mudam para a WebView Incorporada para renderizar opções de gestão de passkeys nos ecrãs de definições onde o controlo de sessão é necessário — embora algumas aplicações simplifiquem isto mantendo a WebView de Sistema para ambos os fluxos. Segundo, as aplicações que já incorporavam o seu fluxo de autenticação em frames de WebView antes de adotarem passkeys continuam este padrão por consistência. A WebView Incorporada com suporte nativo a WebAuthn (AndroidX WebKit 1.12.1+) requer configuração e instalação (permissões, entitlements, definições da WebView), mas já não necessita de código de ponte JavaScript personalizado. Note que a UI Condicional não é suportada na WebView Incorporada. Escolha esta abordagem quando mantiver padrões de autenticação incorporados existentes ou quando precisar de controlo de sessão/cookie para ecrãs pós-autenticação.

Em última análise, as passkeys em aplicações nativas representam um enorme salto em frente tanto na conveniência do utilizador como na segurança. Quer sejam implementadas via Nativa, WebView de Sistema ou WebView Incorporada, eliminam os riscos de phishing e os fardos da gestão de palavras-passe para os seus utilizadores. Implementações do mundo real como a integração de passkeys na aplicação nativa da VicRoads demonstram que as abordagens focadas no nativo proporcionam a maior adoção e satisfação do utilizador quando executadas corretamente com funcionalidades como overlays automáticos de passkey. Seguindo as melhores práticas para uma autenticação amigável ao utilizador e escolhendo a abordagem de implementação que corresponde à arquitetura da sua aplicação — focada no nativo para novas aplicações, WebView de Sistema para fluxos OAuth, ou WebView Incorporada para padrões incorporados existentes — pode oferecer logins sem palavra-passe e biométricos que verdadeiramente realizam a visão das passkeys: autenticação simples, segura e agradável para todos.

Se as passkeys não estiverem a funcionar na sua aplicação nativa, verifique estes problemas comuns por abordagem de implementação:

• Ficheiros servidos sobre HTTPS com certificado válido
• Tipo MIME correto: application/json
• Sem redirecionamentos no caminho .well-known
• iOS: Team ID e Bundle ID correspondem exatamente no ficheiro AASA
• Android: Impressão digital SHA256 corresponde ao seu certificado de assinatura em assetlinks.json
• ID da Relying Party corresponde ao seu domínio (sem protocolo, sem porta)
• Sem barras no final do ID da RP
• Origem do WebAuthn: https://o-seu-dominio.com (não app://)

• iOS: Capacidade de Domínios Associados ativada no Xcode com webcredentials:oseudominio.com
• Android: Digital Asset Links declarados em AndroidManifest.xml
• Utilizador tem bloqueio de ecrã ativado (biométrico ou PIN)
• Testar com o Validador AASA da Apple e a ferramenta de Digital Asset Links da Google
• Verificar se o ficheiro Runner.entitlements contém os domínios associados corretos

• iOS: Usando ASWebAuthenticationSession (recomendado) ou SFSafariViewController
• Android: Usando Chrome Custom Tabs (não uma WebView simples)
• iOS: Verificar se os Domínios Associados estão configurados, se necessário
• Testar se os cookies/credenciais são partilhados com o browser do sistema
• Verificar se a página de autenticação web tem uma implementação WebAuthn adequada

• iOS: Configurada com os entitlements adequados
• iOS: Domínios Associados incluem todos os domínios relevantes
• iOS: Ficheiro AASA acessível e formatado corretamente
• iOS: Testar com ?mode=developer durante o desenvolvimento (remover para produção)
• Android: AndroidX WebKit 1.12.1+ (ou mais recente) incluído no projeto
• Android: Verificação em tempo de execução da funcionalidade WebViewFeature.WEB_AUTHENTICATION
• Android: setWebAuthenticationSupport() chamada com WEB_AUTHENTICATION_SUPPORT_FOR_APP
• Android: JavaScript ativado nas definições da WebView
• Android: Versão do APK da WebView do utilizador suporta a funcionalidade WebAuthn (use deteção de funcionalidades, não a versão do SO)
• UI Condicional não usada (não suportada na WebView Incorporada)
• Recorrer aos Chrome Custom Tabs se a funcionalidade WebAuthn não estiver disponível

• Verificar se o utilizador tem um fornecedor de credenciais não padrão ativo (1Password, Bitwarden, etc.)
• Verificar se o fornecedor suporta passkeys (nem todos os gestores de palavras-passe o fazem)
• Testar com o gestor de credenciais nativo da plataforma (Chaves do iCloud, Gerenciador de Senhas do Google)

"NotAllowedError: The request is not allowed by the user agent or the platform in the current context"

• Normalmente significa: Falta de entitlements (iOS) ou funcionalidade de WebView não disponível/ativada (WebView Incorporada do Android)
• Verificar: Configuração de Domínios Associados, acessibilidade do ficheiro AASA, versão do WebKit, deteção de funcionalidades, chamada a setWebAuthenticationSupport()

Nenhum prompt de passkey aparece

• Pode significar: AASA/assetlinks.json não está a carregar, tipo de WebView errado, ficheiro AASA em cache
• Tentar: Validar ficheiros de associação, usar ?mode=developer no iOS para testes, verificar o tipo de WebView

Para uma depuração detalhada, consulte o nosso artigo sobre IDs da Relying Party em aplicações nativas.

SDKs Nativos da Corbado:

• SDK para iOS (Swift)
• SDK para Android (Kotlin)
• Pacote Flutter

Documentação da Plataforma:

• Apple: Suporte a Passkeys
• Google: Credential Manager

Ferramentas de Validação:

• Validador AASA da Apple
• Gerador de Digital Asset Links da Google