Chaves de acesso no Brave Browser (2026): O que funciona e o que falha

1. Introdução: Suporte a chaves de acesso no Brave hoje#

O suporte a chaves de acesso no Brave é próximo ao do Chromium no nível de código, mas a experiência do usuário diverge em alguns pontos importantes. A partir de abril de 2026, o repositório mais amplo brave/brave-browser ainda tinha 24 problemas abertos correspondentes a passkey ou WebAuthn, enquanto brave/brave-core mostrava uma personalização visível específica para WebAuthn. Os principais pontos de quebra são a interceptação de extensões, solicitações do Windows Hello e fluxos do Android em dispositivos sem serviços do Google.

O Brave fornece chaves de acesso através do mesmo caminho de código WebAuthn do Chromium upstream e delega o armazenamento de credenciais ao sistema operacional. Essa arquitetura faz com que o Brave pareça padrão no papel, mas o comportamento no mundo real ainda depende de sistemas adjacentes como extensões de gerenciadores de senhas, Windows Hello e Google Play Services. As seções abaixo mantêm esses modos de falha separados para que cada comportamento específico da plataforma possa ser compreendido por conta própria.

2. Como a pilha WebAuthn no Brave difere da do Chromium?#

A implementação de WebAuthn do Brave é efetivamente a implementação do Chromium com uma alteração visível de texto na IU. O repositório brave/brave-core contém uma única personalização relacionada ao WebAuthn - uma substituição de string que renomeia "Incognito" para "Private" na caixa de diálogo de salvamento - e nenhum patch em C++ tocando na lógica principal do WebAuthn. Isso significa que o Brave herda a pilha de chaves de acesso do Chromium que o Google lançou a partir do Chromium 115, de junho de 2023 em diante.

Isso importa por duas razões. Primeiro, fusões upstream normais significam que correções do WebAuthn e adições de recursos geralmente chegam sem que o Brave mantenha uma implementação de chaves de acesso profundamente bifurcada (forked). Você pode inspecionar a única substituição de string diretamente em brave/brave-core. Nos mapeamentos AAGUID, o caminho do autenticador de navegador Chromium é comumente identificado como b5397666-4885-aa6b-cebf-e52262a439a2, rotulado como "Chromium Browser" em nossa lista de referência. Segundo, a maioria das falhas relatadas - interceptação de extensões, conflitos de preenchimento automático (autofill) e a dependência do Google Play Services no Android - aparece em sistemas adjacentes, como preenchimento automático, permissões, Shields ou integração com a Carteira (Wallet). Eles envolvem o fluxo do WebAuthn em vez de substituí-lo.

3. Uma chave de acesso criada no macOS pode ser usada no Safari em outro dispositivo da Apple?#

Sim, mas apenas se a chave de acesso for salva no iCloud Keychain. No macOS, o Brave usa a pilha WebAuthn do Chromium e pode armazenar uma nova chave de acesso no autenticador de plataforma da Apple ou em outro destino de armazenamento apresentado no prompt de criação. Uma chave de acesso salva no iCloud Keychain é sincronizada através do ID da Apple e se torna disponível no Safari, Chrome e outros navegadores com capacidade para WebAuthn em dispositivos Apple que compartilhem esse ID da Apple.

Assim que o macOS confirma que o Brave tem permissão para acessar o iCloud Keychain, o navegador pode usar as mesmas chaves de acesso sincronizadas que o Safari vê. Esse prompt de permissão é o momento prático onde a portabilidade entre navegadores em dispositivos Apple se torna real em vez de teórica.

O Brave no macOS também pode participar de fluxos de autenticação entre dispositivos (cross-device). Se o usuário permitir o acesso ao Bluetooth, o Brave pode descobrir e se comunicar com dispositivos próximos durante a CDA (cross-device authentication), o que torna a aprovação de chaves de acesso baseada no telefone amplamente contínua a partir do navegador de desktop.

Uma chave de acesso salva em um armazenamento de perfil de navegador ou em um armazenamento estritamente local não se torna automaticamente disponível no Safari em outro dispositivo Apple. Essa diferença é importante porque a sincronização do autenticador de plataforma no nível do sistema operacional e a sincronização do perfil do navegador seguem regras diferentes. O Brave não possui a sincronização de chaves de acesso do Google Password Manager do Chrome, então apenas o caminho do iCloud Keychain fornece a portabilidade entre navegadores no estilo Apple em dispositivos Apple.

4. Por que as chaves de acesso não funcionam de forma confiável no Android sem o Google Play Services?#

O Android Credential Manager não é, por si só, parte do Google Play Services. No Android 14 e posteriores, o Chromium pode usar o caminho do Credential Manager do sistema, enquanto as versões mais antigas do Android dependem mais da camada FIDO2 baseada no Google Play Services. Na prática, o Brave ainda herda a falha documentada na issue #45415: no GrapheneOS, CalyxOS, /e/OS e outras compilações do Android sem os serviços do Google e sem o caminho necessário do Play Services, o registro e a autenticação de chaves de acesso podem expirar. Em abril de 2026, isso permanecia como uma lacuna de compatibilidade aberta para usuários do Android focados em privacidade.

Esse comportamento está documentado na issue #45415 do brave/brave-browser, aberta em abril de 2025 e ainda aberta um ano depois. A documentação do Credential Manager do Google distingue a API do Credential Manager da dependência opcional de autenticação do Play Services usada em versões mais antigas do Android, e o guia mais amplo do Android observa que o Android 14+ pode funcionar com gerenciadores de senhas ativados. O tópico também observa que o mesmo modo de falha afeta navegadores baseados no Chromium de forma mais ampla, enquanto os navegadores baseados no Firefox não são afetados da mesma forma. O relator original apontou que o GrapheneOS corrigiu a dependência em sua própria bifurcação (fork) do Chromium, o Vanadium, então uma correção downstream parece tecnicamente possível - ela simplesmente não aconteceu.

Vários usuários confirmaram o comportamento independentemente naquele tópico. Um teste especialmente limpo em dezembro de 2025 usou o mesmo dispositivo com dois perfis: as chaves de acesso funcionaram no Brave apenas no perfil com o Play Services ativado, enquanto o Vanadium e o Cromite funcionaram em ambos. A partir de abril de 2026, nenhum mantenedor do Brave havia respondido no tópico. Para o público do Android focado em privacidade do Brave - que inclui um número desproporcional de usuários sem serviços do Google

• isso deixa uma lacuna muito visível. O Firefox no Android usa sua própria pilha WebAuthn e não depende do Play Services da mesma forma. Hoje, a solução prática é usar o Firefox para fluxos de chaves de acesso no Android sem Play Services, ou recorrer a uma chave de segurança de hardware com um cliente compatível. Para o cenário mais amplo de falhas no Android, veja Erros de chaves de acesso em aplicativos nativos. Para as especificidades do Google Play Services e do Credential Manager, veja Códigos de erro de chave de acesso do Android e do Google Play Services.

5. Por que os prompts de chave de acesso do Windows Hello aparecem mesmo quando eu os desativo?#

Desativar a configuração do Brave de "oferecer salvar chaves de acesso" não impede que o Windows Hello apareça durante os fluxos WebAuthn. Assim que um site chama o WebAuthn e o Windows Hello está registrado, o Windows anuncia o Hello como um autenticador de plataforma e o Brave não expõe um controle voltado para o usuário que o bloqueie. Em janeiro de 2026, a supressão do Windows Hello permanecia não resolvida para os usuários que queriam o Hello para desbloqueio de dispositivo, mas não para chaves de acesso.

A Issue #51858, aberta em janeiro de 2026, e o tópico mais longo da comunidade 646042 descrevem a mesma coisa. O relator original tentou edições de registro, políticas de grupo, alternância de flags e instalações limpas - nada disso alterou o comportamento.

A razão técnica descrita no tópico 646042 é simples: as configurações do gerenciador de senhas do navegador controlam o próprio comportamento de preenchimento automático do navegador, não o limite do WebAuthn entre a página e o sistema operacional. O Windows expõe o Hello de forma independente, e a discussão não identifica uma configuração documentada e suportada que preserve o Windows Hello para desbloqueio de dispositivo enquanto o bloqueia totalmente como um autenticador de plataforma WebAuthn.

Hoje, a única maneira confiável de suprimir esses prompts é desativar totalmente o registro do Windows Hello, o que obviamente entra em conflito com a forma como a maioria das pessoas deseja desbloquear seus dispositivos. O Edge se comporta de maneira diferente porque está mais intimamente integrado à camada de gerenciamento de credenciais do Windows e expõe controles que as bifurcações (forks) do Chromium atualmente não expõem. Para uma visão mais ampla do comportamento de chaves de acesso no Windows, veja Chaves de acesso no Windows 11.

6. Você deve armazenar chaves de acesso nativamente ou no seu gerenciador de senhas?#

O armazenamento nativo de chaves de acesso é a opção mais simples dentro de um único ecossistema, enquanto extensões de gerenciadores de senhas continuam sendo a única camada de sincronização multiplataforma amplamente viável. O iCloud Keychain funciona bem em dispositivos Apple, o Windows Hello funciona no Windows e cofres baseados em extensão como o 1Password ou o Bitwarden continuam sendo a única opção realista para usuários que desejam que as chaves de acesso estejam disponíveis nativamente e de forma consistente no Windows, macOS, Linux e Android. A autenticação entre dispositivos (CDA, ou transporte híbrido via código QR e Bluetooth) ainda pode conectar dispositivos no momento do login, mas não sincroniza a própria credencial ou a torna localmente disponível em todos os lugares por padrão. O contraponto é a confiabilidade: fluxos nativos são mais simples, fluxos de extensão são mais portáteis e a CDA é melhor entendida como um caminho de fallback em vez de uma estratégia de armazenamento.

A decisão se resume principalmente a três coisas: quantas plataformas você usa, o quanto você confia em fluxos de extensão e onde você já guarda suas credenciais. Se você permanece principalmente dentro de um ecossistema de sistema operacional - tudo Apple ou tudo Windows - a rota do autenticador de plataforma nativo é a opção mais limpa. Nessa configuração, o Brave se comporta de maneira muito parecida com o Chrome ou o Safari. Se você precisar que as chaves de acesso o acompanhem no Windows, macOS, Linux e Android, uma extensão de gerenciador de senhas de terceiros, como 1Password, Bitwarden, Dashlane ou Proton Pass, ainda é a única camada de sincronização amplamente viável.

A complicação é que, desde abril de 2024, continuam chegando relatos de que a IU nativa de chaves de acesso intercepta intermitentemente fluxos orientados por extensões. Os usuários na issue #37762 descrevem caixas de diálogo de autenticação do sistema operacional aparecendo, embora o Bitwarden ou o 1Password devessem ser donos da credencial. Até março de 2026, a antiga solução alternativa - desativar brave://flags/#web-authentication-new-passkey-ui - não estava mais disponível porque a flag havia sido removida na versão 146.

Na prática, o padrão com o qual muitos usuários focados em privacidade acabam em 2026 é híbrido: use o autenticador de plataforma do SO para logins diários dentro de um ecossistema, use uma extensão de gerenciador de senhas onde a portabilidade multiplataforma seja importante e mantenha uma chave de segurança de hardware por perto para contas de alto valor.

7. Quais são os pontos problemáticos das chaves de acesso que os usuários relatam em 2026?#

Os problemas abertos sobre chaves de acesso do Brave em 2026 se agrupam em torno de três temas recorrentes: interceptação por extensões, falhas no Android em dispositivos sem serviços do Google e problemas com chaves de segurança no desktop. A partir de abril de 2026, o repositório mais amplo ainda mostrava 24 problemas abertos correspondentes a webauthn ou passkey, o que sugere que o atrito está concentrado, e não aleatório.

O grupo mais movimentado é a interceptação por extensões, onde a IU nativa de chaves de acesso pode substituir prompts do 1Password, Bitwarden ou Dashlane. A compatibilidade do Android sem o Google Play Services é o segundo problema recorrente, e a detecção de chaves de segurança em desktops é o terceiro. Os tópicos de problemas mais referenciados aqui são #37762, #50561, #45415, #15650, #43043, #34441, #33237 e #51858. Os tópicos ativos apontam na mesma direção sem precisar de muitas citações diretas.

Vários desses problemas receberam novos comentários nos últimos 90 dias, o que os torna regressões ativas em vez de curiosidades históricas. Para os desenvolvedores que criam fluxos de chaves de acesso, a conclusão é clara: teste os fluxos orientados por extensões no Brave explicitamente e ofereça alternativas (fallbacks) sensatas quando as chamadas WebAuthn falharem. Para os usuários, a lição é igualmente prática: mantenha uma chave de segurança de hardware ou outro fator de recuperação configurado em contas de alto valor.

8. Conclusão#

A história das chaves de acesso no Brave é limpa no nível de código e confusa no nível de experiência do usuário. O caminho WebAuthn é efetivamente o do Chromium, com apenas uma substituição de string confirmando o quão próxima a implementação permanece do upstream. Nas plataformas da Apple, a portabilidade de chaves de acesso funciona exatamente como os usuários esperam porque o iCloud Keychain é dono da credencial. O atrito real está em outro lugar: interceptação por extensões (#37762), supressão do Windows Hello (#51858) e a dependência do Google Play Services no Android (#45415). Até que esses problemas sejam resolvidos, os desenvolvedores devem testar o Brave separadamente, em vez de assumir a paridade com o Chrome, e os usuários devem manter um fallback forte - idealmente uma chave de segurança de hardware - para contas importantes.

9. Sobre a Corbado#

A Corbado constrói infraestrutura de chaves de acesso para login de consumidores e fornece uma plataforma de inteligência de chaves de acesso para equipes que precisam operar chaves de acesso e sistemas de autenticação em escala. Publicamos análises técnicas de comportamentos de WebAuthn e de chaves de acesso em navegadores e sistemas operacionais com base em implantações reais, inspeção direta do código-fonte e leitura atenta das especificações subjacentes. Perguntas ou correções são sempre bem-vindas.

10. Perguntas frequentes#

10.1 Uma chave de acesso criada no Brave no macOS pode ser usada no Safari em outro dispositivo da Apple?#

Sim, mas apenas se o Brave salvar a chave de acesso no iCloud Keychain. No macOS, o Brave usa a pilha WebAuthn do Chromium e pode armazenar uma nova chave de acesso no iCloud Keychain ou em outro destino de armazenamento mostrado no prompt de criação. Uma chave de acesso salva no iCloud Keychain é sincronizada através do ID da Apple e fica disponível no Safari, Chrome e outros navegadores em dispositivos da Apple que compartilham esse ID da Apple. Uma chave de acesso salva em um armazenamento de perfil do navegador ou armazenamento estritamente local não se torna automaticamente disponível no Safari em outro dispositivo Apple.

10.2 Por que as chaves de acesso falham no Brave no Android sem o Google Play Services?#

O Brave no Android pode falhar sem o Google Play Services, mas o motivo é mais específico do que "O Credential Manager é parte do Play Services". O Credential Manager do Android é uma API de sistema e Jetpack, enquanto as versões mais antigas do Android dependem mais da camada FIDO2 baseada no Google Play Services. Na prática, o Brave ainda herda a falha documentada no problema #45415 do brave/brave-browser: no GrapheneOS, CalyxOS ou outras compilações do Android sem serviços do Google e sem o caminho necessário do Play Services, a caixa de diálogo da chave de acesso nunca abre e o registro ou a autenticação expira (timeout).

Para o cenário mais amplo de falhas no Android, veja Erros de chaves de acesso em aplicativos nativos. Para as especificidades do Google Play Services e do Credential Manager, veja Códigos de erro de chave de acesso do Android e do Google Play Services.

10.3 O Brave sincroniza chaves de acesso entre dispositivos como o Chrome?#

Não. O Brave não fornece um equivalente à sincronização de chaves de acesso do perfil de navegador do Chrome através do Google Password Manager. As chaves de acesso criadas no Brave são armazenadas no autenticador de plataforma do SO subjacente - iCloud Keychain na Apple, Windows Hello no Windows e Android Credential Manager no Android - e são sincronizadas apenas por meio dessa conta do SO. Se você deseja uma sincronização consistente entre dispositivos, você depende do fornecedor do SO ou de uma extensão de gerenciador de senhas de terceiros.

10.4 Por que o Brave solicita chaves de acesso do Windows Hello mesmo quando desativo as opções de chaves de acesso nas configurações?#

A opção brave://password-manager/settings do Brave apenas controla se o Brave oferece para salvar chaves de acesso por si mesmo. Isso não impede que o Windows anuncie o Windows Hello como um autenticador de plataforma WebAuthn para a página. O site invoca o WebAuthn, o Windows apresenta o Hello e o Brave não tem nenhum botão no navegador para suprimir a caixa de diálogo do SO. O comportamento é rastreado no problema #51858 do brave/brave-browser.

10.5 Devo armazenar as chaves de acesso no fluxo nativo do Brave ou no meu gerenciador de senhas?#

Use o fluxo de SO nativo do Brave (iCloud Keychain ou Google Password Manager através da plataforma) se você permanecer dentro de um ecossistema e quiser o mínimo de partes móveis. Use uma extensão de gerenciador de senhas de terceiros, como o 1Password ou o Bitwarden, se precisar de chaves de acesso para acompanhá-lo no Windows, macOS, Linux e Android de forma consistente, ou se você já guarda seus segredos lá. Desde 2024, a IU nativa do Brave interceptou repetidamente fluxos de chaves de acesso de extensões, por isso vale a pena verificar se a extensão ainda possui a propriedade do prompt.

10.6 Quantos problemas abertos de WebAuthn e de chaves de acesso o repositório brave/brave-browser tem atualmente sobre o comportamento de chaves de acesso do Brave?#

A partir de abril de 2026, o brave/brave-browser tinha 24 problemas abertos correspondentes a pesquisas por passkey ou WebAuthn. Os problemas abertos marcados com chaves de acesso cresceram de cerca de 2 por ano em 2022-2023 para 6 abertos em 2025. Para o Brave, os temas dominantes são a interceptação por extensões no desktop, supressão do Windows Hello e dependência do Google Play Services no Android.

Sobre a Corbado

Corbado é a Authentication 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 →