WebAuthn Relying Party ID (rpID) e passkeys: domínios e apps nativos

A autenticação com chaves de acesso está se tornando rapidamente a norma, à medida que gigantes da tecnologia como TikTok, GitHub e WhatsApp, X (Twitter), LinkedIn e Amazon as lançam ou já o fizeram. É evidente que o mundo tecnológico está reconhecendo a importância de uma autenticação simples e segura.

Além da experiência de usuário perfeita de se autenticar com Face ID, Touch ID ou Windows Hello, as chaves de acesso oferecem segurança incomparável em comparação com métodos de autenticação tradicionais como senhas. Um dos recursos de destaque é sua forte resistência a phishing.

Cheatsheet de Passkeys. Guias práticos, padrões de implementação e KPIs para programas de passkeys.

Obter cheat sheet

Teste passkeys em uma demo ao vivo.

Testar passkeys

Um ataque de phishing é um ataque onde a vítima é enganada para fornecer credenciais a um site falso que imita o site original. Por exemplo, imagine receber um e-mail do que parece ser o seu banco, pedindo que você faça login. Você clica no link e o site parece legítimo, então você insere suas credenciais e o invasor pode usá-las para fazer login no site original. Este é um problema cada vez maior na era digital e até mesmo grandes empresas como Okta (um provedor de autenticação!) ou Retool foram vítimas de ataques de spear-phishing (uma forma especial de phishing onde vítimas individuais são particularmente visadas com truques de phishing muito pessoais), enfatizando a necessidade de medidas de segurança robustas.

Pelo contrário, se você usar uma chave de acesso e o site for falso, sua autenticação falhará. Isso ocorre porque as chaves de acesso estão vinculadas aos domínios para os quais foram criadas através do Relying Party ID.

Esse mecanismo está embutido no WebAuthn, o padrão da web subjacente à chave de acesso para autenticação sem senha. O WebAuthn é construído sobre duas cerimônias principais: a cerimônia de registro e a de autenticação.

Durante a cerimônia de registro (inscrição), uma nova chave de acesso é criada para um serviço online (a Relying Party) através de um app web ou nativo. Nesse processo, o domínio (Relying Party ID) para o qual a chave de acesso é criada é armazenado na chave de acesso.

Isso permite que a cerimônia de autenticação (login) verifique se o serviço online (a Relying Party), ao qual o app web ou nativo pertence, corresponde ao Relying Party ID armazenado na chave de acesso.

A seguir, veremos em detalhes como esse processo de correspondência de domínios funciona e como, em particular, os apps nativos são protegidos.

O Relying Party ID é essencialmente um domínio armazenado na chave de acesso, garantindo que a chave de acesso só funcione se a URL atual do navegador (a origem do usuário que é enviada automaticamente em cada solicitação) corresponder a ele (veja a abordagem de app nativo abaixo). É um componente crucial da especificação WebAuthn, na qual você pode se aprofundar aqui. O Relying Party ID pode ser o domínio raiz (por exemplo, corbado.com) ou um subdomínio (auth.corbado.com). Você não pode armazenar o domínio raiz como Relying Party ID se ele estiver na lista de sufixos públicos (encontre a lista e as bibliotecas para detecção de sufixos públicos aqui). Alterar o Relying Party ID de um serviço online quebrará as chaves de acesso existentes (exceções: o novo Relying Party ID é um subdomínio do antigo Relying Party ID, ou Related Origin Requests estão configurados via .well-known/webauthn para permitir o reuso de chaves de acesso em domínios relacionados).

Durante o processo de autenticação, o Relying Party ID é verificado em relação à URL do navegador (origem do usuário) para garantir que eles correspondam. Correspondência nesse sentido significa que:

• A URL do navegador (origem do usuário) corresponde exatamente ao Relying Party ID OU
• A URL do navegador (origem do usuário) é um subdomínio que corresponde ao Relying Party ID e o domínio pai é registrável (por exemplo, com ou qualquer domínio na Public Suffix List não funciona)

Aqui está um esboço detalhado de qual originalHost (segunda coluna) tem permissão para acessar seu domínio pai:

A seguir, você vê as PublicKeyCredentialCreationOptions analisadas:

{
    "publicKey": {
        "attestation": "direct",
        "authenticatorSelection": {
            "authenticatorAttachment": "platform",
            "requireResidentKey": false,
            "userVerification": "preferred"
        },
        "challenge": "qNqrdXUrk5S7dCM1MAYH3qSVDXznb-6prQoGqiACR10=",
        "excludeCredentials": [],
        "pubKeyCredParams": [
            {
                "alg": -7,
                "type": "public-key"
            }
        ],
        "rp": {
            "id": "corbado.com",
            "name": "Corbado"
        },
        "timeout": 30000,
        "user": {
            "displayName": "Corbado user",
            "id": "bz9ZDfHzOBLycqISTAdWwWIZt8VO-6mT3hBNXS5jwmY="
        }
    }
}

rp significa Relying Party.

Um dos principais benefícios do Relying Party ID é a prevenção de ataques de phishing. Imagine o seguinte cenário:

1. Um invasor desenvolve um clone do PayPal, que é um site falso que tenta roubar suas credenciais do PayPal para fazer login em seu nome e enviar dinheiro para a conta do invasor. Este site falso do PayPal está hospedado no domínio paybal.com (por isso, muitas vezes não é visível que é um domínio diferente à primeira vista).
2. Você já criou uma chave de acesso no passado para o site legítimo do PayPal. Esta chave de acesso armazenou o Relying Party ID paypal.com.
3. Você visita o site falso do PayPal em paybal.com (ao visitar este site, a origem de sua solicitação é paybal.com*) e o site envia ao seu dispositivo (o autenticador) um desafio para o Relying Party ID paypal.com (aqui ele tenta enganá-lo) e pede que você o assine com sua chave de acesso para o Relying Party ID paypal.com.
4. Seu dispositivo (o autenticador) verifica se a origem da solicitação (paypal.com) e o Relying Party ID que ele armazenou na chave de acesso (paypal.com) correspondem.
5. Como eles obviamente não correspondem, a autenticação falha e impede que você dê a algum invasor acesso à sua conta do PayPal.

O diagrama a seguir ilustra esse mecanismo de prevenção de phishing.

No caso de um app nativo, o manuseio da origem difere por plataforma: No Android, a origem é formatada como android:apk-key-hash:<SHA256_fingerprint>. No iOS, a origem da web do WebAuthn é a origem da web do RP (por exemplo, https://paypal.com). Em ambos os casos, a confiança entre seu app nativo e o servidor é verificada através do arquivo de associação correspondente (veja abaixo). Para informações detalhadas sobre como a validação de origem funciona para apps nativos, consulte nosso guia dedicado sobre validação de origem WebAuthn para apps nativos.

Participe da nossa comunidade de passkeys para atualizações e suporte.

Entrar

Para implementar chaves de acesso em um app nativo, um desenvolvedor pode decidir entre adicioná-las via WebView ou nativamente. Vamos examinar os benefícios e as desvantagens de ambas as abordagens a seguir.

Usar um WebView* para integrar chaves de acesso significa embutir um navegador web dentro do app nativo para lidar com o processo de autenticação. Essa abordagem exibe essencialmente uma página da web dentro do app, facilitando o reuso de fluxos de autenticação baseados na web sem ter que reescrevê-los para a plataforma nativa. No entanto, existem algumas desvantagens. Os WebViews podem não suportar todos os recursos das chaves de acesso e há um risco potencial de ataques "man-in-the-middle" se não forem implementados com segurança. Além disso, a experiência do usuário pode não ser tão suave quanto as integrações nativas, e pode haver desafios na manutenção do comportamento consistente em diferentes dispositivos e versões do sistema operacional.

*Existem vários tipos de WebViews: No iOS (WKWebView, SFSafariViewController ou SFAuthenticationSession / ASWebAuthenticationSession para fluxos de autenticação baseados em OAuth/OpenID Connect) e Android (WebView, CCT-Chrome Custom Tabs). Consulte este artigo do blog para obter detalhes. Recomendamos o uso do SFSafariViewController/ ASWebAuthenticationSession e Chrome Custom Tabs no contexto de chaves de acesso se você não quiser uma integração nativa.

Veja quantas pessoas realmente usam passkeys.

Ver dados de adoção

Integração nativa envolve a construção da funcionalidade da chave de acesso diretamente no app iOS ou Android usando APIs e bibliotecas específicas da plataforma. Esse método oferece uma experiência de usuário mais perfeita, pois não há necessidade de fazer a transição entre o app nativo e um WebView. Ele também permite um melhor desempenho e uma aparência mais consistente. Do ponto de vista da segurança, a integração nativa pode oferecer proteção aprimorada contra certos tipos de ataques, especialmente quando combinada com recursos de segurança específicos da plataforma. No entanto, o esforço de implementação pode ser maior, pois os desenvolvedores precisam escrever e manter código separado para cada plataforma (Android e iOS). Além disso, manter-se atualizado com as especificações mais recentes de chaves de acesso / WebAuthn pode exigir atualizações de app mais frequentes.

A seguir, nos concentramos na integração nativa de chaves de acesso.

Veja quantas pessoas realmente usam passkeys.

Ver dados de adoção

Os apps nativos (por exemplo, apps iOS ou Android) apresentam um desafio em comparação aos apps web. Diferente dos apps web, não há URL do navegador para corresponder ao Relying Party ID. Mesmo assim, para garantir o mesmo nível de segurança, os domínios são conectados a apps nativos através de arquivos de associação, para que a confiança entre um domínio e um app nativo seja estabelecida.

Isso é particularmente importante se uma chave de acesso foi criada em um app web e deve ser usada para o mesmo Relying Party ID em um app nativo (e vice-versa).

O iOS usa o arquivo apple-app-site-association. Este arquivo contém vários direitos (entitlements), mas para o WebAuthn e as chaves de acesso, o direito webcredentials é importante.

{
    "webcredentials": {
        "apps": ["9RF9KY88B2.com.corbado.passkeys"]
    }
}

Em webcredentials.apps, você precisa armazenar seu Application Identifier Prefix (por exemplo, 9RF9KY77B2) e seu Bundle Identifier (por exemplo, com.corbado.passkeys).

Para que os apps nativos do iOS funcionem, o arquivo apple-app-site-association deve ser armazenado no diretório /.well-known do Relying Party ID (https://<Relying Party ID>/.well-known/apple-app-site-association).

Veja um exemplo ao vivo aqui.

O Android usa o arquivo assetlinks.json, que, assim como seu equivalente no iOS, requer configurações particulares para WebAuthn e chaves de acesso.

[
    {
        "relation": [
            "delegate_permission/common.handle_all_urls",
            "delegate_permission/common.get_login_creds"
        ],
        "target": {
            "namespace": "android_app",
            "package_name": "com.corbado.passkeys.pub",
            "sha256_cert_fingerprints": [
                "F8:90:4E:9A:99:01:71:75:25:38:D5:36:16:2D:B3:65:EB:41:51:D4:53:9A:72:BC:4B:56:C5:16:43:62:E2:C0"
            ]
        }
    }
]

Você precisa ter os valores de relation delegate_permission/common.handle_all_urls e delegate_permission/common.get_login_creds definidos. Além disso, você precisa adicionar o nome do seu pacote e a impressão digital SHA-256 do seu certificado de assinatura.

Para permitir o compartilhamento de uma chave de acesso entre um app nativo e um app web, você precisa adicionar duas entradas. Uma para o namespace web e uma para o namespace android_app.

Veja um exemplo ao vivo aqui.

Para que os apps do Android funcionem, o arquivo assetlinks.json deve ser armazenado no diretório /.well-known do Relying Party ID https://<Relying Party ID>/.well-known/assetlinks.json - portanto, muito parecido com o iOS.

Confira este artigo do blog para ver um exemplo de implementação que compartilha chaves de acesso entre um app nativo do Android/iOS e um app web.

Experimente fluxos de passkeys no Passkeys Debugger.

Testar grátis

O processo para estabelecer a confiança entre um app iOS e um app web é o seguinte:

1. O desenvolvedor do app iOS precisa especificar uma lista de domínios que ele deseja associar ao app nativo. Esses domínios são codificados (hardcoded) nos direitos do app iOS, por exemplo:

• webcredentials:auth.Corbado.com
• webcredentials:*.Corbado.com

2. Toda vez que o app iOS for instalado ou atualizado, o iOS fará o download do arquivo apple-app-site-association para cada entrada da lista de direitos do app iOS.

3. Quando uma credencial (por exemplo, chave de acesso) é criada dentro de um app iOS, o app iOS valida se o domínio do servidor da relying party está associado ao app iOS verificando os dois aspectos a seguir:

• Existe um arquivo apple-app-site-association para este domínio do servidor da relying party no dispositivo?
• O app iOS está listado nesse arquivo apple-app-site-association?

Se, e somente se, ambas as perguntas puderem ser respondidas com sim, uma chave de acesso pode ser criada dentro do app iOS.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

O processo para estabelecer a confiança entre um app Android e um app web é o seguinte:

1. O desenvolvedor do app Android precisa especificar uma lista de domínios que ele deseja associar ao app Android. Esses domínios são armazenados como destinos com o namespace web no arquivo assetlinks.json. Para declarar que os apps Android e os apps web compartilham credenciais, delegate_permission/common.get_login_creds precisa ser especificado. Encontre detalhes aqui.

2. Se uma chave de acesso for criada dentro do app Android, o app Android validará se o Relying Party ID está associado ao app Android verificando o assetlinks.json:

• Existe um arquivo assetlinks.json para este Relying Party ID em https://<Relying Party ID>./well-known/assetlinks.json?
• O app Android está definido corretamente como um alvo?

3. Se, e somente se, ambas as perguntas puderem ser respondidas com sim, uma chave de acesso pode ser criada dentro do app Android.

O diagrama abaixo compara esses processos de estabelecimento de confiança lado a lado.

Assine nosso Substack de passkeys para receber as últimas novidades.

Assinar

A seguir, fornecemos uma visão geral detalhada das diferentes configurações que são necessárias para configurar adequadamente a autenticação com chaves de acesso para apps nativos.

Para o Flutter, a regra respectiva do Android ou iOS se aplica. A única configuração específica do Flutter é o registro dos arquivos de associação, onde você deve adicionar:

• Para Android: flutter_deeplinking_enabled no AndroidManifest.xml
• Para iOS: FlutterDeepLinkingEnabled true no Info.plist

Como nós mesmos experimentamos, trabalhar com Relying Party IDs, diferentes níveis de (sub)domínios e CNAMEs pode ser uma tarefa bastante desafiadora, apresentamos quatro exemplos distintos e explicamos por que e como eles funcionam.

Observe que a linha CNAME da tabela não é necessária para a autenticação com chave de acesso e é apenas o resultado de nossa pesquisa que queríamos adicionar.

Neste exemplo, o arquivo apple-app-site-association / assetlinks.json para Corbado.com pode ser baixado sem nenhum problema quando o app nativo é instalado / atualizado, porque o arquivo está na mesma localização do Relying Party ID.

Uma chave de acesso para o Relying Party ID pode ser criada.

Neste exemplo, o arquivo apple-app-site-association / assetlinks.json para auth.corbado.com pode ser baixado sem nenhum problema quando o app nativo é instalado / atualizado, porque o arquivo está no local do Relying Party ID, já que o CNAME aponta do Relying Party ID para a localização armazenada.

Uma chave de acesso para o Relying Party ID pode ser criada.

Neste exemplo, o arquivo apple-app-site-association / assetlinks.json para auth.corbado.com pode ser baixado sem problemas quando o app nativo é instalado/atualizado, porque o arquivo está, devido ao CNAME, no local onde auth.corbado.com o espera.

MAS: O apple-site-association-file / assetlinks.json para corbado.com não pode ser baixado quando o app nativo é instalado/atualizado, porque o arquivo não está em https://corbado.com/.well-known/apple-app-site-association / https://corbado.com/.well-known/assetlinks.json, onde é esperado, e nenhum CNAME está apontando para ele.

Uma chave de acesso para o Relying Party ID não pode ser criada.

Neste exemplo, o arquivo apple-app-site-association para corbado.com pode ser baixado sem nenhum problema, quando o app nativo é instalado / atualizado, porque o arquivo está onde é esperado e o entitlement de webcredentials (*.corbado.com) corresponde ao Relying Party ID (auth.corbado.com). Observe que este exemplo não funciona para o Android, pois o Android não funciona com algo como entitlements curinga (wildcard). Em geral, essa maneira de definir Relying Party IDs não é recomendada.

Uma chave de acesso para o Relying Party ID pode ser criada.

Participe da nossa comunidade de passkeys para atualizações e suporte.

Entrar

Erro:

Você começou a desenvolver e definiu um subdomínio (por exemplo, login.acme.com) como seu Relying Party ID. Os primeiros usuários criaram uma chave de acesso para este Relying Party ID. Então, você nota que também precisa dessas chaves de acesso para autenticação em outro subdomínio (por exemplo, app.acme.com). Como a origem de um usuário e o Relying Party ID para o novo subdomínio não correspondem, o usuário não pode fazer login com a chave de acesso. Mudar o Relying Party ID nas suas configurações de WebAuthn para acme.com invalidaria todas as chaves de acesso existentes, pois a nova origem e o Relying Party ID armazenado nas chaves de acesso existentes não correspondem.

Solução:

Verifique duplamente no início, ao definir seu Relying Party ID, pois isso é mais ou menos definitivo. Se você não tem certeza e quer estar pronto para o futuro, o que significa que outros subdomínios no futuro podem precisar da chave de acesso para autenticação, recomendamos que use o domínio raiz (por exemplo, acme.com) como Relying party ID, a menos que ele esteja na Public Suffix List.

Erro:

Você está desenvolvendo um app nativo e web simultaneamente. Para agilizar as coisas, você usa dois servidores WebAuthn diferentes (com diferentes Relying Party IDs para o app nativo e web). À medida que seus usuários criam as primeiras chaves de acesso, o respectivo Relying Party ID é armazenado na chave de acesso. Permitir login entre dispositivos / plataformas com a mesma chave de acesso, por exemplo, com uma chave de acesso criada em um app web e tentando entrar em um app nativo, não é mais possível. Mesclar os dois servidores WebAuthn abandonará as chaves de acesso que foram registradas com o servidor WebAuthn antigo (Relying Party ID antigo) e seus usuários não poderão fazer login com essas chaves de acesso.

Solução:

Se você tiver vários aplicativos (por exemplo, um app web e um app nativo), tenha sempre apenas um servidor WebAuthn e defina apenas um Relying Party ID para todos os seus apps. A vinculação entre esses aplicativos pode ser feita através das etapas descritas acima.

Erro:

Você começou a desenvolver seu aplicativo, configurou os arquivos de associação e os implantou no seu servidor. Por algum motivo, você ainda está recebendo mensagens de erro e não encontra a causa raiz.

Solução:

Uma causa potencial para a mensagem de erro pode ser um arquivo de associação malformado ou inacessível. Antes de implantar qualquer arquivo de associação em um servidor, recomendamos fortemente que verifique a validade e acessibilidade (muitas vezes esses arquivos podem estar por trás de uma VPN robusta ou firewall que impede o acesso adequado dos crawlers da Apple e do Google) de um arquivo de associação através das ferramentas fornecidas para iOS e Android.

Erro:

Você implantou seu arquivo apple-app-site-association no seu servidor e deseja começar a criar imediatamente uma chave de acesso em seu dispositivo de teste. Por algum motivo, você não consegue criar a chave de acesso e recebe mensagens de erro.

Solução:

O motivo por trás dessas mensagens de erro é que os dispositivos iOS baixam o arquivo apple-app-site-association para validar a Relying Party. Para isso, os dispositivos iOS não enviam uma solicitação direta para o seu servidor, mas usam uma CDN. Tanto o dispositivo quanto a CDN armazenam em cache o arquivo apple-app-site-association depois que ele for recuperado com sucesso. Devido a essa funcionalidade de cache, as novas mudanças em seu arquivo apple-app-site-association não são refletidas diretamente em seu app. Pode levar até 24 horas até que a CDN armazene em cache o arquivo apple-app-site-association. Para contornar essa restrição durante o desenvolvimento, você pode adicionar ?mode=developer ao Relying Party ID e desabilitar totalmente o cache (por exemplo, o Relying Party ID seria acme.com?mode=developer).

Erro:

Você começou a desenvolver um app Android e deseja testá-lo em um emulador Android. Por algum motivo, você está recebendo mensagens de erro, mesmo tendo configurado o emulador Android corretamente e outros apps parecem funcionar perfeitamente nele.

Solução:

As versões do Android, o suporte da Play Store e as versões da API desempenham um papel importante ao testar um aplicativo de chaves de acesso. Além disso, você precisa estar logado em uma conta do Google. Consulte nossa seção de solução de problemas para obter detalhes.

Nossa recomendação geral é escolher o seu Relying Party ID com cuidado, com base na paisagem do seu aplicativo e requisitos. Abaixo, coletamos os casos de uso mais comuns, mas nossa recomendação geral é que você deve buscar escolher o seu domínio raiz como o seu Relying Party ID e configurar a sua autenticação dessa maneira. Com a Corbado, nós também já pré-configuramos isso para você dessa forma (como parte da nossa abordagem para oferecer uma autenticação de chaves de acesso contínua para todas as configurações técnicas. Nossos componentes de interface de usuário (UI) e SDKs estão preparados para serem usados com o seu domínio raiz como Relying Party ID).

A seguir, fornecemos uma árvore de decisão muito específica que deve ajudar a determinar o Relying Party ID correto e como você deve lidar / hospedar os arquivos de associação ao usar a Corbado como sua solução de chaves de acesso.

A primeira decisão é se você está em um ambiente de desenvolvimento ou de produção. O próximo nível de decisão que você deve tomar é baseado na paisagem do seu aplicativo: você tem apenas um app nativo ou um app nativo e um app web.

Para o ambiente de desenvolvimento, assumimos que você quer iniciar o desenvolvimento e testes rapidamente. O Relying Party ID pode ser alterado depois, se você quiser colocar em produção.

• Definir Relying Party ID = pro-XXX.frontendapi.cloud.corbado.io (valor padrão)
• A Corbado hospeda o arquivo de associação para você
• Nenhuma tarefa pendente de DNS para você

Não é fácil testar o app web e o app nativo ao mesmo tempo

Opção 1:

Ou você define Relying Party ID = pro-XXX.frontendapi.cloud.corbado.io (app nativo funciona) OU define Relying Party ID = localhost (app web funciona)

Opção 2:

A única solução para app nativo e web funcionarem ao mesmo tempo é usar um proxy reverso local (é uma solução meio improvisada):

• Definir Relying Party ID = acme-dev.com
• Definir CNAME de acme-dev.com => pro-XXX.frontendapi.cloud.corbado.io
• Adicionar entrada /etc/hosts local localhost acme-dev.com
• Adicionar proxy reverso (nginx) com regra para acme-dev.com => localhost:3000 (como um exemplo)

No ambiente de produção, você precisa decidir se você está satisfeito com um subdomínio como o Relying Party ID (por exemplo, auth.acme.com) ou se você quer um domínio raiz como o Relying Party ID (por exemplo, acme.com)

• Definir Relying Party ID = auth.acme.com
• A Corbado hospeda o arquivo de associação para você
• Definir CNAME de auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io

• Definir Relying Party ID = auth.acme.com
• A Corbado hospeda o arquivo de associação para você
• Definir CNAME de auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io (também necessário para os cookies funcionarem se você usar o gerenciamento de sessões da Corbado)

• Definir Relying Party ID = acme.com
• Hospedar o arquivo de associação você mesmo no seu próprio servidor em acme.com/.well-known/<association file>
• Nenhuma tarefa pendente de DNS para você

• Definir Relying Party ID = acme.com
• Hospedar o arquivo de associação você mesmo no seu próprio servidor em acme.com/.well-known/<association file>
• Se você usar o gerenciamento de sessões da Corbado, você precisa definir CNAME de auth.acme.com => pro-XXX.frontendapi.cloud.corbado.io para fazer os cookies funcionarem (este CNAME não é necessário para o Relying Party ID, apenas para o gerenciamento de sessão)

A árvore de decisão a seguir resume todos os caminhos de configuração.

O Relying Party ID é uma pedra angular do WebAuthn e da autenticação baseada em chaves de acesso e fornece uma forte resistência a phishing. Configurá-lo adequadamente, entender as complexidades de correspondência de domínios e garantir a implantação correta para apps nativos é crucial. Esta postagem do blog mostrou como configurá-los corretamente e como lidar com diferentes erros. Depois que a sua configuração de rpID estiver sólida, concentre-se na otimização dos fluxos de criação de chaves de acesso e fluxos de login com chaves de acesso para impulsionar a adoção real. Para mais ideias sobre como configurar chaves de acesso para app nativo, recomendamos ler sobre chaves de acesso no Flutter.

Se você tiver mais dúvidas ou precisar de assistência, não hesite em entrar em contato.

Sobre a Corbado

Corbado é a Passkey Intelligence Platform para times de CIAM que rodam autenticação consumer em escala. Mostramos o que logs de IDP e ferramentas genéricas de analytics não enxergam: quais dispositivos, versões de SO, navegadores e gerenciadores de credenciais suportam passkeys, por que os registros não viram logins, onde o fluxo WebAuthn falha e quando uma atualização de SO ou navegador quebra silenciosamente o login — tudo sem substituir Okta, Auth0, Ping, Cognito ou seu IDP interno. Dois produtos: Corbado Observe adiciona observabilidade para passkeys e qualquer outro método de login. Corbado Connect entrega passkeys gerenciados com analytics integrado (junto ao seu IDP). VicRoads roda passkeys para mais de 5M de usuários com Corbado (+80% de ativação de passkey). Fale com um especialista em Passkeys →

O autenticador compara a origem real do navegador com o Relying Party ID armazenado na chave de acesso. Se um invasor hospedar um site falso em um domínio diferente, a incompatibilidade de origem fará com que a autenticação falhe automaticamente, mesmo que o desafio falsificado reivindique um RP ID legítimo. Essa vinculação significa que uma chave de acesso registrada em paypal.com não pode ser usada em um domínio parecido como paybal.com.

Alterar o RP ID invalida todas as chaves de acesso existentes porque o RP ID armazenado em cada credencial não corresponderá mais ao novo valor. As únicas exceções são quando o novo RP ID é um subdomínio do antigo ou quando Related Origin Requests são configurados via .well-known/webauthn. Escolha o domínio raiz como RP ID desde o início para evitar este problema irreversível.

O iOS não busca o arquivo apple-app-site-association diretamente do seu servidor. Ele usa a CDN da Apple, que pode levar até 24 horas para armazenar em cache um arquivo recém-implantado ou atualizado. Durante o desenvolvimento, anexe ?mode=developer ao Relying Party ID para contornar o cache inteiramente.

O uso do domínio raiz (por exemplo, acme.com) é recomendado porque as chaves de acesso criadas em qualquer subdomínio podem se autenticar em todos os subdomínios desse raiz. Um RP ID de subdomínio restringe o uso da chave de acesso a esse subdomínio e seus filhos, o que pode quebrar fluxos entre subdomínios posteriormente. Se você tiver vários domínios raiz, como acme.com e acme.co.uk, configure Related Origin Requests via .well-known/webauthn para permitir a reutilização de chaves de acesso entre eles.