---
url: 'https://www.corbado.com/pt/blog/chaves-de-acesso-brave-browser'
title: 'Chaves de acesso no Brave Browser (2026): O que funciona e o que falha'
description: 'O Brave segue o Chromium em chaves de acesso, mas conflitos no Android, Windows Hello e gerenciadores de senhas ainda criam atritos reais para os usuários.'
lang: 'pt'
author: 'Vincent Delitz'
date: '2026-07-03T07:07:35.047Z'
lastModified: '2026-07-03T07:08:26.598Z'
keywords: 'chaves de acesso no brave, webauthn no brave, brave browser, gerenciador de senhas, windows hello, fido2, google play services'
category: 'WebAuthn Know-How'
---

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

## Key Facts

- **O caminho de código do WebAuthn é o do Chromium, quase intacto.** O repositório
  `brave/brave-core` contém exatamente **uma** personalização visível relacionada ao WebAuthn: uma
  substituição de string que renomeia o rótulo "Incognito" (Anônimo) do Chrome para "Private" (Privado) na
  caixa de diálogo de salvamento de chaves de acesso. Nenhum patch em C++ altera o caminho de código do WebAuthn.
- **24 problemas abertos sobre chaves de acesso/WebAuthn** estavam no `brave/brave-browser` em abril de 2026, com base
  em pesquisas de problemas no GitHub por `passkey` e `WebAuthn`. Os problemas abertos marcados com passkey cresceram
  de \~2/ano em 2022-2023 para 6 abertos em 2025.
- **O uso entre navegadores no macOS funciona.** Uma chave de acesso criada no macOS pode ser armazenada no
  iCloud Keychain e é utilizável no Safari, Chrome e outros navegadores da plataforma Apple em dispositivos
  que compartilham o mesmo ID da Apple.
- **As compilações do Android sem serviços do Google falham.** Sem o Google Play Services, o registro
  e a autenticação de chaves de acesso falham frequentemente no Android. Rastreado no problema #45415 (aberto desde abril
  de 2025\).
- **O Windows Hello não pode ser totalmente suprimido.** Desativar
  `brave://password-manager/settings` não impede que o Windows ofereça o Hello como um
  autenticador de plataforma WebAuthn. Rastreado no problema #51858 (aberto em janeiro de 2026).
- **A interceptação por extensões é a regressão mais ativa.** O problema #37762 - onde a
  IU nativa de chaves de acesso substitui os prompts do Bitwarden e 1Password - foi aberto em abril de 2024 e
  ainda estava recebendo relatórios de bugs em 25 de março de 2026.
- **A solução alternativa da flag `web-authentication-new-passkey-ui` desapareceu** na versão 146
  (Chromium 146), de acordo com o relato de um usuário no problema #37762 do `brave/brave-browser` datado de
  25-03-2026.

## 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`](https://github.com/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`](https://github.com/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`](https://github.com/brave/brave-core/blob/master/components/webauthn_strings_override.grdp).
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 macOS pergunta se o Brave Browser pode acessar as chaves de acesso salvas no iCloud Keychain, o que permite que as mesmas credenciais sincronizadas funcionem no Safari, Chrome e Brave em dispositivos Apple que compartilham o mesmo ID da Apple.](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/access_icloud_8252555e93.png)

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.

![O Brave no macOS pede acesso ao Bluetooth antes da autenticação entre dispositivos, ativando a descoberta de dispositivos próximos e fluxos mais suaves de aprovação de chaves de acesso baseados no telefone.](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/bluetooth_brave_macos_c51dd36600.png)

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`](https://github.com/brave/brave-browser/issues/45415),
aberta em abril de 2025 e ainda aberta um ano depois. A
[documentação do Credential Manager](https://developer.android.com/training/sign-in/passkeys) 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](https://github.com/GrapheneOS/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](https://github.com/brave/brave-browser/issues/51858), aberta em janeiro
de 2026, e o tópico mais longo da
[comunidade 646042](https://community.brave.app/t/brave-prompts-for-windows-hello-passkeys-even-when-disabled/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](https://github.com/brave/brave-browser/issues/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.

| Local de armazenamento  | Sincronização entre SOs | Uso entre navegadores     | Postura de recuperação    | Risco conhecido                    |
| ----------------------- | ----------------------- | ------------------------- | ------------------------- | ---------------------------------- |
| iCloud Keychain         | Somente Apple           | Navegadores Apple         | ID da Apple               | Nenhum                             |
| Windows Hello           | Não (vinculado ao dispositivo) | Mesmo dispositivo Windows | Desbloqueio de dispositivo / PIN | A caixa de diálogo do Hello não pode ser desativada |
| Google Password Manager | Onde o GPM está disponível | Chrome + superfícies Android | Conta do Google           | Não exposto nos perfis do Brave aqui |
| 1Password / Bitwarden   | Total                   | Total (extensão)          | Conta do cofre            | Interceptação nativa intermitente  |
| Chave de segurança de hardware | Vinculado ao dispositivo | Qualquer navegador        | Posse física              | Nenhum                             |

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`](https://github.com/brave/brave-browser/issues/37762),
[`#50561`](https://github.com/brave/brave-browser/issues/50561),
[`#45415`](https://github.com/brave/brave-browser/issues/45415),
[`#15650`](https://github.com/brave/brave-browser/issues/15650),
[`#43043`](https://github.com/brave/brave-browser/issues/43043),
[`#34441`](https://github.com/brave/brave-browser/issues/34441),
[`#33237`](https://github.com/brave/brave-browser/issues/33237) e
[`#51858`](https://github.com/brave/brave-browser/issues/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.
