Esta página se tradujo automáticamente. Lee la versión original en inglés aquí.
brave/brave-core contiene exactamente una personalización visible relacionada
con WebAuthn: una anulación de cadena que cambia el nombre de la etiqueta "Incógnito"
de Chrome a "Privado" en el cuadro de diálogo para guardar claves de acceso. Ningún
parche de C++ toca la ruta del código de WebAuthn.brave/brave-browser hasta abril de 2026, según las búsquedas de problemas de GitHub
para passkey y WebAuthn. Los problemas abiertos etiquetados con claves de acceso
crecieron de ~2 por año en 2022-2023 a 6 abiertos en 2025.brave://password-manager/settings no impide que Windows ofrezca Hello como un
autenticador de plataforma WebAuthn. Rastreado en el problema #51858 (abierto en enero de 2026).web-authentication-new-passkey-ui ha desaparecido
en la versión 146 (Chromium 146), según el informe de un usuario en el problema #37762
de brave/brave-browser con fecha del 25 de marzo de 2026.El soporte de claves de acceso de Brave es muy similar al de Chromium a nivel de código, pero
la experiencia del usuario difiere en algunos puntos importantes. Hasta abril de 2026,
el repositorio más amplio brave/brave-browser todavía tenía 24 problemas abiertos
que coincidían con passkey o WebAuthn, mientras que
brave/brave-core mostraba una sola
personalización visible específica de WebAuthn. Los principales puntos de ruptura son
la interceptación de extensiones, los avisos de Windows Hello y
los flujos de Android en dispositivos sin Google.
Brave implementa las claves de acceso a través de la misma ruta de código de WebAuthn que la versión original de Chromium y delega el almacenamiento de credenciales al sistema operativo. Esa arquitectura hace que Brave parezca estándar en teoría, pero el comportamiento en el mundo real aún depende de sistemas circundantes como las extensiones de administradores de contraseñas, Windows Hello y Google Play Services. Las siguientes secciones mantienen separados esos modos de fallo para que cada comportamiento específico de la plataforma se pueda entender por sí solo.
La implementación de WebAuthn en Brave es, a todos los efectos, la implementación de Chromium
con un solo cambio visible en el texto de la interfaz de usuario. El repositorio
brave/brave-core contiene una sola
personalización relacionada con WebAuthn -una anulación de cadena que cambia el nombre
de "Incógnito" a "Privado" en el cuadro de diálogo de guardado- y no hay parches de C++
que toquen la lógica central de WebAuthn. Esto significa que Brave hereda la pila de
claves de acceso de Chromium que Google envió desde Chromium 115 a partir de junio de 2023.
Esto es importante por dos razones. En primer lugar, las fusiones ascendentes normales
significan que las correcciones de WebAuthn y las nuevas funciones generalmente llegan
sin que Brave tenga que mantener una implementación de claves de acceso profundamente dividida.
Puede inspeccionar la única anulación de cadena directamente en
brave/brave-core.
En las asignaciones de AAGUID, la ruta del autenticador del navegador Chromium
se identifica comúnmente como b5397666-4885-aa6b-cebf-e52262a439a2,
etiquetada como "Navegador Chromium" en nuestra lista de referencias.
En segundo lugar, la mayoría de los fallos notificados -interceptación de extensiones,
conflictos de autocompletado y la dependencia de Google Play Services en Android-
aparecen en sistemas adyacentes como el autocompletado, los permisos, Shields o
la integración de Wallet. Rodean el flujo de WebAuthn en lugar de reemplazarlo.
Sí, pero solo si la clave de acceso se guarda en iCloud Keychain. En macOS, Brave utiliza la pila WebAuthn de Chromium y puede almacenar una nueva clave de acceso en el autenticador de plataforma de Apple o en otro destino de almacenamiento presentado en el aviso de creación. Una clave de acceso guardada en iCloud Keychain se sincroniza a través del Apple ID y pasa a estar disponible en Safari, Chrome y otros navegadores compatibles con WebAuthn en dispositivos Apple que compartan ese Apple ID.
Una vez que macOS confirma que Brave tiene permiso para acceder a iCloud Keychain, el navegador puede usar las mismas claves de acceso sincronizadas que ve Safari. Ese aviso de permiso es el momento práctico en el que la portabilidad entre navegadores en los dispositivos Apple se vuelve real en lugar de teórica.
Brave en macOS también puede participar en flujos de autenticación entre dispositivos (CDA). Si el usuario permite el acceso a Bluetooth, Brave puede descubrir y comunicarse con dispositivos cercanos durante la CDA, lo que hace que la aprobación de la clave de acceso a través del teléfono se sienta en gran medida perfecta desde el navegador de escritorio.
Una clave de acceso guardada en un almacén de perfiles del navegador o en un almacén local no estará disponible automáticamente en Safari en otro dispositivo Apple. Esa diferencia importa porque la sincronización del autenticador de plataforma a nivel de sistema operativo y la sincronización de perfiles del navegador siguen reglas diferentes. Brave no incluye la sincronización de claves de acceso de Google Password Manager de Chrome, por lo que solo la ruta de iCloud Keychain proporciona una portabilidad entre navegadores al estilo de Apple en dispositivos Apple.
Android Credential Manager no forma parte de Google Play Services en sí mismo. En Android 14 y versiones posteriores, Chromium puede usar la ruta del sistema Credential Manager, mientras que las versiones anteriores de Android dependen en mayor medida de la capa FIDO2 respaldada por Google Play Services. En la práctica, Brave sigue heredando el fallo documentado en el problema #45415: en GrapheneOS, CalyxOS, /e/OS y otras compilaciones de Android sin Google que no tienen la ruta necesaria de Play Services, el registro y la autenticación de claves de acceso pueden agotar el tiempo de espera. Hasta abril de 2026, esto seguía siendo una brecha de compatibilidad abierta para los usuarios de Android centrados en la privacidad.
Este comportamiento está documentado en
el problema #45415 de brave/brave-browser,
abierto en abril de 2025 y que sigue abierto un año después. La
documentación de Credential Manager
de Google distingue la API de Credential Manager de la dependencia de autenticación opcional
de Play Services utilizada en versiones anteriores de Android, y la guía más amplia de Android
señala que Android 14+ puede funcionar con administradores de contraseñas habilitados.
El hilo también señala que el mismo modo de fallo afecta a los navegadores basados en Chromium
en general, mientras que los navegadores basados en Firefox no se ven afectados de la misma
manera. El autor del informe original señaló que GrapheneOS aplicó un parche a la dependencia
en su propia bifurcación de Chromium, Vanadium,
por lo que una solución técnica descendente parece posible; simplemente no ha sucedido.
Varios usuarios confirmaron de forma independiente el comportamiento en ese hilo. Una prueba especialmente limpia en diciembre de 2025 utilizó el mismo dispositivo con dos perfiles: las claves de acceso funcionaban en Brave solo en el perfil con Play Services habilitado, mientras que Vanadium y Cromite funcionaban en ambos. A partir de abril de 2026, ningún mantenedor de Brave había respondido en el hilo. Para la audiencia de Android centrada en la privacidad de Brave, que incluye un número desproporcionado de usuarios sin Google, esto deja una brecha muy visible. Firefox en Android utiliza su propia pila WebAuthn y no depende de Play Services de la misma manera. En la actualidad, la solución práctica es usar Firefox para los flujos de claves de acceso en dispositivos Android sin Play Services, o recurrir a una llave de seguridad de hardware con un cliente compatible. Para un panorama más amplio de los fallos en Android, consulte los Errores de claves de acceso en aplicaciones nativas. Para conocer los detalles de Google Play Services y Credential Manager, consulte los Códigos de error de claves de acceso en Android y Google Play Services.
Deshabilitar la configuración "ofrecer guardar claves de acceso" de Brave no impide que Windows Hello aparezca durante los flujos de WebAuthn. Una vez que un sitio llama a WebAuthn y Windows Hello está inscrito, Windows anuncia a Hello como un autenticador de plataforma y Brave no expone un control de cara al usuario que lo bloquee. Hasta enero de 2026, la supresión de Windows Hello seguía sin resolverse para los usuarios que querían Hello para el desbloqueo del dispositivo pero no para las claves de acceso.
El problema #51858, abierto en enero de 2026, y el hilo de la comunidad 646042 más extenso describen lo mismo. El informante original intentó editar el registro, las políticas de grupo, activar y desactivar banderas e instalaciones limpias; nada de eso cambió el comportamiento.
La razón técnica descrita en el hilo 646042 es simple: la configuración del administrador de contraseñas del navegador controla el comportamiento de autocompletado del propio navegador, no el límite de WebAuthn entre la página y el sistema operativo. Windows expone a Hello de forma independiente, y la discusión no identifica una configuración documentada y compatible que preserve Windows Hello para el desbloqueo de dispositivos mientras lo bloquea por completo como un autenticador de plataforma WebAuthn.
Hoy en día, la única forma confiable de suprimir esos avisos es deshabilitar la inscripción en Windows Hello por completo, lo que obviamente choca con la forma en que la mayoría de las personas quieren desbloquear su dispositivo. Edge se comporta de manera diferente porque está más estrechamente integrado con la capa de administración de credenciales de Windows y expone controles que las bifurcaciones de Chromium actualmente no tienen. Para una mirada más amplia al comportamiento de las claves de acceso en Windows, consulte Claves de acceso en Windows 11.
El almacenamiento nativo de claves de acceso es la opción más sencilla dentro de un solo ecosistema, mientras que las extensiones de administrador de contraseñas siguen siendo la única capa de sincronización multiplataforma ampliamente viable. iCloud Keychain funciona bien en todos los dispositivos Apple, Windows Hello funciona en Windows y las bóvedas basadas en extensiones como 1Password o Bitwarden siguen siendo la única opción realista para los usuarios que desean que las claves de acceso estén disponibles de forma nativa en Windows, macOS, Linux y Android. La autenticación entre dispositivos (CDA, o transporte híbrido a través de código QR y Bluetooth) aún puede unir dispositivos en el momento del inicio de sesión, pero no sincroniza la credencial en sí ni la hace disponible localmente en todas partes de forma predeterminada. El equilibrio está en la confiabilidad: los flujos nativos son más simples, los flujos de extensiones son más portátiles y es mejor entender el CDA como una ruta de respaldo en lugar de una estrategia de almacenamiento.
La decisión se reduce principalmente a tres cosas: cuántas plataformas usa, cuánto confía en los flujos de extensiones y dónde guarda ya sus credenciales. Si permanece principalmente dentro del ecosistema de un sistema operativo, todo Apple o todo Windows, la ruta del autenticador de plataforma nativo es la opción más limpia. En esa configuración, Brave se comporta de manera muy similar a Chrome o Safari. Si necesita que las claves de acceso lo sigan a través de Windows, macOS, Linux y Android, una extensión de administrador de contraseñas de terceros como 1Password, Bitwarden, Dashlane o Proton Pass sigue siendo la única capa de sincronización ampliamente viable.
La complicación es que, desde abril de 2024, han seguido llegando informes de que la interfaz
de usuario nativa de la clave de acceso secuestra intermitentemente los flujos impulsados
por extensiones. Los usuarios en el
problema #37762 describen
que aparecen cuadros de diálogo de autenticación del sistema operativo a pesar de que
Bitwarden o 1Password deberían ser los dueños de la credencial. Para marzo de 2026, la
antigua solución alternativa, deshabilitar brave://flags/#web-authentication-new-passkey-ui,
ya no estaba disponible porque la bandera se había eliminado en la versión 146.
| Ubicación de almacenamiento | Sincronización entre sistemas operativos | Uso entre navegadores | Postura de recuperación | Riesgo conocido |
|---|---|---|---|---|
| iCloud Keychain | Solo Apple | Navegadores Apple | Apple ID | Ninguno |
| Windows Hello | No (vinculado al dispositivo) | Mismo dispositivo Windows | Desbloqueo del dispositivo / PIN | El cuadro de diálogo de Hello no se puede deshabilitar |
| Google Password Manager | Donde GPM esté disponible | Chrome + superficies Android | Cuenta de Google | No expuesto en perfiles de Brave aquí |
| 1Password / Bitwarden | Completa | Completo (extensión) | Cuenta de la bóveda | Interceptación nativa intermitente |
| Llave de seguridad de hardware | Vinculada al dispositivo | Cualquier navegador | Posesión física | Ninguno |
En la práctica, el patrón con el que terminan muchos usuarios centrados en la privacidad en 2026 es uno híbrido: use el autenticador de plataforma del sistema operativo para los inicios de sesión diarios dentro de un ecosistema, use una extensión de administrador de contraseñas donde importe la portabilidad multiplataforma y tenga a mano una llave de seguridad de hardware para las cuentas de alto valor.
Los problemas abiertos de claves de acceso de Brave en 2026 se agrupan en torno a tres
temas recurrentes: la interceptación de extensiones, fallos en Android en dispositivos
sin Google y problemas con llaves de seguridad en computadoras de escritorio.
A partir de abril de 2026, el repositorio más amplio todavía mostraba 24 problemas
abiertos que coincidían con webauthn o passkey, lo que sugiere que la fricción
está concentrada, no es aleatoria.
El grupo más concurrido es el de la interceptación de extensiones, donde la interfaz
de usuario nativa de la clave de acceso puede anular las solicitudes de 1Password, Bitwarden
o Dashlane. La compatibilidad de Android sin Google Play Services es el segundo
problema recurrente, y la detección de llaves de seguridad en el escritorio es el tercero.
Los hilos de problemas a los que se hace referencia con más frecuencia aquí son
#37762,
#50561,
#45415,
#15650,
#43043,
#34441,
#33237 y
#51858.
Los hilos activos apuntan en la misma dirección sin necesidad de muchas citas directas.
Varios de estos problemas recibieron nuevos comentarios en los últimos 90 días, lo que los convierte en regresiones activas en lugar de curiosidades históricas. Para los desarrolladores que construyen flujos de claves de acceso, la conclusión es clara: pruebe explícitamente los flujos impulsados por extensiones en Brave y ofrezca alternativas sensatas cuando fallen las llamadas de WebAuthn. Para los usuarios, la lección es igualmente práctica: mantenga configurada una llave de seguridad de hardware u otro factor de recuperación en sus cuentas de alto valor.
La historia de las claves de acceso en Brave es limpia a nivel de código y desordenada a nivel de experiencia del usuario. La ruta de WebAuthn es efectivamente la de Chromium, con solo una anulación de cadena que confirma qué tan cerca se mantiene la implementación de la original. En las plataformas Apple, la portabilidad de las claves de acceso funciona exactamente como esperan los usuarios porque iCloud Keychain es el propietario de la credencial. La fricción real se encuentra en otras partes: interceptación de extensiones (#37762), supresión de Windows Hello (#51858) y la dependencia de Google Play Services de Android (#45415). Hasta que se resuelvan esos problemas, los desarrolladores deben probar Brave por separado en lugar de asumir la paridad de Chrome y los usuarios deben mantener un fuerte respaldo, idealmente una llave de seguridad de hardware, para las cuentas importantes.
Corbado construye infraestructura de claves de acceso para el inicio de sesión del consumidor y proporciona una plataforma de inteligencia de claves de acceso para equipos que necesitan operar claves de acceso y sistemas de autenticación a gran escala. Publicamos análisis técnicos del comportamiento de WebAuthn y las claves de acceso en navegadores y sistemas operativos basados en implementaciones reales, inspección directa de fuentes y lectura detenida de las especificaciones subyacentes. Las preguntas o correcciones son siempre bienvenidas.
Sí, pero solo si Brave guarda la clave de acceso en iCloud Keychain. En macOS, Brave usa la pila WebAuthn de Chromium y puede almacenar una nueva clave de acceso en iCloud Keychain o en otro destino de almacenamiento que se muestra en el aviso de creación. Una clave de acceso guardada en iCloud Keychain se sincroniza a través del Apple ID y estará disponible en Safari, Chrome y otros navegadores en dispositivos Apple que compartan ese Apple ID. Una clave de acceso guardada en un almacén de perfiles del navegador o en un almacén local no estará disponible automáticamente en Safari en otro dispositivo Apple.
Brave en Android puede fallar sin Google Play Services, pero el motivo es más específico
que "Credential Manager forma parte de Play Services". Android Credential Manager es
un sistema y una API de Jetpack, mientras que las versiones anteriores de Android
dependen más de la capa FIDO2 respaldada por Google Play Services. En la práctica,
Brave sigue heredando el fallo documentado en el problema #45415 de brave/brave-browser:
en GrapheneOS, CalyxOS u otras compilaciones de Android sin Google que no tengan
la ruta necesaria de Play Services, el cuadro de diálogo de la clave de acceso
nunca se abre y el registro o la autenticación se agotan.
Para un panorama más amplio de los fallos en Android, consulte Errores de claves de acceso en aplicaciones nativas. Para conocer los detalles de Google Play Services y Credential Manager, consulte Códigos de error de claves de acceso en Android y Google Play Services.
No. Brave no proporciona un equivalente a la sincronización de claves de acceso de perfil del navegador de Chrome a través de Google Password Manager. Las claves de acceso creadas en Brave se almacenan en el autenticador de plataforma del sistema operativo subyacente: iCloud Keychain en Apple, Windows Hello en Windows y Android Credential Manager en Android, y se sincronizan solo a través de esa cuenta del sistema operativo. Si desea una sincronización consistente entre dispositivos, confíe en el proveedor del sistema operativo o en una extensión de administrador de contraseñas de terceros.
El interruptor de brave://password-manager/settings de Brave solo controla si
Brave se ofrece a guardar las claves de acceso. No impide que Windows anuncie a
Windows Hello como un autenticador de plataforma WebAuthn a la página. El sitio
invoca WebAuthn, Windows presenta Hello y Brave no tiene un interruptor en el
navegador para suprimir el cuadro de diálogo del sistema operativo. El
comportamiento se rastrea en el problema #51858 de brave/brave-browser.
Use el flujo de sistema operativo nativo de Brave (iCloud Keychain o Google Password Manager a través de la plataforma) si se mantiene dentro de un ecosistema y desea la menor cantidad de partes móviles. Use una extensión de administrador de contraseñas de terceros como 1Password o Bitwarden si necesita que las claves de acceso lo sigan a través de Windows, macOS, Linux y Android de manera consistente, o si ya guarda sus secretos allí. Desde 2024, la interfaz de usuario nativa de Brave ha interceptado repetidamente los flujos de claves de acceso de extensiones, por lo que vale la pena verificar que la extensión siga siendo dueña del aviso.
Hasta abril de 2026, brave/brave-browser tenía 24 problemas abiertos que coincidían
con búsquedas de passkey o WebAuthn. Los problemas abiertos etiquetados con claves
de acceso crecieron de aproximadamente 2 por año en 2022-2023 a 6 abiertos en 2025.
Para Brave, los temas dominantes son la interceptación de extensiones en el escritorio,
la supresión de Windows Hello y la dependencia de Google Play Services en Android.
Corbado es la Authentication Intelligence Platform para equipos de CIAM que gestionan autenticación de consumidores a gran escala. Te ayudamos a ver lo que los logs de tu IDP y las herramientas de analytics genéricas no muestran: qué dispositivos, versiones de SO, navegadores y gestores de credenciales soportan passkeys, por qué los registros no se convierten en inicios de sesión, dónde falla el flujo de WebAuthn y cuándo una actualización de SO o navegador rompe el login en silencio — todo sin reemplazar Okta, Auth0, Ping, Cognito o tu IDP propio. Dos productos: Corbado Observe aporta observabilidad para passkeys y cualquier otro método de login. Corbado Connect añade passkeys gestionados con analytics integrado (junto a tu IDP). VicRoads ejecuta passkeys para más de 5M de usuarios con Corbado (+80 % de activación de passkey). Habla con un experto en Passkeys →
Mira cómo Corbado encaja con tu despliegue de passkeys y tu stack de autenticación actual.
Explorar la Console
Artículos relacionados
Tabla de contenidos