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 Passkey 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