--- url: 'https://www.corbado.com/zh/blog/passkeys-brave-browser' title: 'Brave浏览器中的通行密钥（2026）：哪些正常工作，哪些会出问题' description: 'Brave在通行密钥方面主要遵循Chromium，但Android、Windows Hello和密码管理器冲突仍会造成实际的阻碍。' lang: 'zh' author: 'Vincent Delitz' date: '2026-07-03T07:08:08.479Z' lastModified: '2026-07-03T07:08:26.485Z' keywords: 'Brave浏览器中的通行密钥, 通行密钥, passkeys, Brave browser' category: 'WebAuthn Know-How' --- # Brave浏览器中的通行密钥（2026）：哪些正常工作，哪些会出问题 ## Key Facts - **WebAuthn代码路径几乎完全沿用Chromium。** `brave/brave-core`存储库中仅包含**一个**可见的WebAuthn相关自定义：将通行密钥保存对话框中的Chrome“Incognito”标签重命名为“Private”的字符串覆盖。没有任何C++补丁触及WebAuthn代码路径。 - **截至2026年4月，`brave/brave-browser`中存在24个未决的通行密钥/WebAuthn问题。** 这是基于GitHub对`passkey`和`WebAuthn`的问题搜索得出的。标记为通行密钥的未决问题从2022-2023年的每年约2个增长到2025年新开的6个。 - **macOS跨浏览器使用正常。** 在macOS上创建的通行密钥可以存储在iCloud钥匙串中，并可以在共享相同Apple ID的设备上的Safari、Chrome和其他Apple平台浏览器中使用。 - **去Google化的Android版本会出错。** 在没有Google Play服务的情况下，Android上的通行密钥注册和身份验证经常失败。在问题#45415中被跟踪（自2025年4月起未决）。 - **Windows Hello无法被完全抑制。** 禁用`brave://password-manager/settings`并不会阻止Windows将Hello作为WebAuthn平台身份验证器提供。在问题#51858（2026年1月开启）中被跟踪。 - **扩展拦截是最活跃的退化问题。** 原生通行密钥UI覆盖Bitwarden和1Password提示的问题#37762于2024年4月开启，并在2026年3月25日仍在接收错误报告。 - **`web-authentication-new-passkey-ui`标志的变通方法在版本146（Chromium 146）中已被移除**，这是根据用户于2026-03-25在`brave/brave-browser`问题#37762中的报告。 ## 1. 简介：Brave目前的通行密钥支持 Brave的通行密钥支持在代码级别上与Chromium很接近，但在几个重要地方的用户体验存在差异。截至2026年4月，更广泛的`brave/brave-browser`存储库仍然有24个匹配`passkey`或`WebAuthn`的未决问题，而[`brave/brave-core`](https://github.com/brave/brave-core)显示了一个可见的特定于WebAuthn的自定义。主要的断点是扩展拦截、Windows Hello提示和去Google化设备上的Android流程。 Brave通过与上游Chromium相同的WebAuthn代码路径提供通行密钥，并将凭证存储委托给操作系统。这种架构使Brave在纸面上看起来很标准，但现实世界的行为仍然取决于周边系统，例如密码管理器扩展、Windows Hello和Google Play服务。以下部分将这些故障模式分开，以便可以单独理解每个特定于平台的行为。 ## 2. Brave中的WebAuthn技术栈与Chromium的有什么不同？ Brave的WebAuthn实现实际上就是Chromium的实现，只有一处可见的UI文本更改。[`brave/brave-core`](https://github.com/brave/brave-core)存储库包含一个与WebAuthn相关的自定义——在保存对话框中将“Incognito”重命名为“Private”的字符串覆盖——没有任何C++补丁触及WebAuthn的核心逻辑。这意味着Brave继承了Google从2023年6月的Chromium 115开始发布并在后续版本中采用的Chromium通行密钥栈。 这之所以重要，有两个原因。首先，正常的上游合并意味着WebAuthn的修复和新功能通常会直接到达，而Brave不需要维护深度分支的通行密钥实现。您可以直接在[`brave/brave-core`](https://github.com/brave/brave-core/blob/master/components/webauthn_strings_override.grdp)中检查这个孤立的字符串覆盖。在AAGUID映射中，Chromium浏览器身份验证器路径通常被识别为`b5397666-4885-aa6b-cebf-e52262a439a2`，在我们的参考列表中标记为“Chromium Browser”。其次，大多数报告的故障——扩展拦截、自动填充冲突和Android对Google Play服务的依赖——出现在相邻系统中，如自动填充、权限、Shields或钱包集成。它们围绕着WebAuthn流程，而不是取代它。 ## 3. 在macOS上创建的通行密钥可以在另一台Apple设备的Safari中使用吗？ 可以，但前提是将通行密钥保存到iCloud钥匙串。在macOS上，Brave使用Chromium的WebAuthn技术栈，并且可以将新通行密钥存储在Apple平台身份验证器中，或者存储在创建提示中显示的另一个存储目标中。保存到iCloud钥匙串的通行密钥通过Apple ID同步，并可在共享该Apple ID的Apple设备上的Safari、Chrome和其他支持WebAuthn的浏览器中使用。 一旦macOS确认允许Brave访问iCloud钥匙串，浏览器就可以使用Safari所看到的相同的同步通行密钥。这个权限提示是Apple设备上跨浏览器可移植性从理论变为现实的实际时刻。 ![macOS询问Brave浏览器是否可以访问保存在iCloud钥匙串中的通行密钥，从而使得相同的同步凭据可以在共享相同Apple ID的Apple设备上的Safari、Chrome和Brave中使用。](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/access_icloud_8252555e93.png) macOS上的Brave也可以参与跨设备身份验证（CDA）流程。如果用户允许蓝牙访问，Brave可以在CDA期间发现附近的设备并与之通信，这使得从桌面浏览器进行基于手机的通行密钥批准感觉大部分是无缝的。 ![macOS上的Brave在跨设备身份验证前请求蓝牙访问，从而实现附近设备的发现并提供更顺畅的基于手机的通行密钥批准流程。](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/bluetooth_brave_macos_c51dd36600.png) 保存到浏览器配置文件存储或仅限本地的存储的通行密钥，不会自动在另一台Apple设备的Safari中变得可用。这种差异很重要，因为OS级别的平台身份验证器同步和浏览器配置文件同步遵循不同的规则。Brave没有提供Chrome的Google密码管理器通行密钥同步功能，因此只有iCloud钥匙串路径在Apple设备上提供了Apple风格的跨浏览器可移植性。 ## 4. 为什么在没有Google Play服务的Android上，通行密钥无法可靠地工作？ Android的凭据管理器本身不是Google Play服务的一部分。在Android 14及更高版本上，Chromium可以使用系统凭据管理器路径，而较旧的Android版本更严重地依赖由Google Play服务支持的FIDO2层。在实践中，Brave仍然继承了问题#45415中记录的故障：在GrapheneOS、CalyxOS、/e/OS和其他没有所需Play服务路径的去Google化Android版本上，通行密钥注册和身份验证可能会超时。截至2026年4月，这对注重隐私的Android用户来说仍然是一个未解决的兼容性空白。 该行为记录在[`brave/brave-browser`问题#45415](https://github.com/brave/brave-browser/issues/45415)中，于2025年4月开启并在一年后仍然未解决。Google的[凭据管理器文档](https://developer.android.com/training/sign-in/passkeys)区分了凭据管理器API与旧Android版本上使用的可选Play服务身份验证依赖项，而更广泛的Android指南指出，Android 14+可以与已启用的密码管理器一起工作。该主题还指出，相同的故障模式更广泛地影响基于Chromium的浏览器，而基于Firefox的浏览器不受以相同方式的影响。最初的报告者指出，GrapheneOS在其自己的Chromium分支[Vanadium](https://github.com/GrapheneOS/Vanadium)中修补了该依赖项，因此下游修复在技术上看起来是可行的——只是尚未发生。 多名用户在该主题中独立证实了此行为。2025年12月的一项特别清晰的测试在具有两个配置文件的同一设备上进行：在Brave中通行密钥仅在启用了Play服务的配置文件上工作，而Vanadium和Cromite在两者上都能正常工作。截至2026年4月，没有Brave维护人员在该主题中回复。对于Brave以隐私为中心的Android受众（其中包括不成比例的去Google化用户）来说，这留下了非常明显的空白。Android上的Firefox使用自己的WebAuthn技术栈，不以相同方式依赖Play服务。目前的实际变通方法是在非Play服务的Android上使用Firefox进行通行密钥流程，或者退回到具有兼容客户端的硬件安全密钥。有关更广泛的Android故障情况，请参阅原生应用通行密钥错误。有关Google Play服务和凭据管理器的具体信息，请参阅Android和Google Play服务通行密钥错误代码。 ## 5. 为什么即使我禁用了Windows Hello通行密钥提示，它们仍会出现？ 禁用Brave的“提供保存通行密钥”设置不会阻止Windows Hello在WebAuthn流程期间出现。一旦网站调用WebAuthn且Windows Hello已注册，Windows就会将Hello推广为平台身份验证器，而Brave没有提供一个面向用户的控件来阻止它。截至2026年1月，对于希望使用Hello解锁设备但不希望将其用于通行密钥的用户来说，抑制Windows Hello仍未解决。 [问题#51858](https://github.com/brave/brave-browser/issues/51858)（2026年1月开启）和更长的[社区主题646042](https://community.brave.app/t/brave-prompts-for-windows-hello-passkeys-even-when-disabled/646042)描述了同样的事情。最初的报告者尝试了注册表编辑、组策略、标志切换和全新安装——均未改变此行为。 主题646042中描述的技术原因很简单：浏览器密码管理器设置控制浏览器自己的自动填充行为，而不是页面与OS之间的WebAuthn边界。Windows独立地暴露Hello，讨论未指明在保留用于设备解锁的Windows Hello的同时将其作为WebAuthn平台身份验证器完全阻止的记录的且受支持的配置。 如今，抑制这些提示的唯一可靠方法是完全禁用Windows Hello注册，这显然与大多数人希望解锁其设备的方式相冲突。Edge的行为不同，因为它与Windows的凭据管理层集成得更紧密，并暴露了Chromium分支目前没有的控制机制。有关Windows通行密钥行为的更广泛视角，请参阅Windows 11上的通行密钥。 ## 6. 您应该在原生存储中还是密码管理器中存储通行密钥？ 在单个生态系统中，原生通行密钥存储是最简单的选项，而密码管理器扩展仍然是唯一广泛可行的跨平台同步层。iCloud钥匙串跨Apple设备表现良好，Windows Hello在Windows上可用，而基于扩展的密码库（例如1Password或Bitwarden）仍然是希望在Windows、macOS、Linux和Android上原生使用通行密钥的用户的唯一现实选择。跨设备身份验证（CDA，即通过二维码和蓝牙的混合传输）仍然可以在登录时桥接设备，但它不会同步凭证本身，也不会默认在所有地方使其在本地可用。这是一种权衡：原生流程更简单，扩展流程更便携，而CDA最好理解为一种后备路径而不是存储策略。 该决定很大程度上取决于三件事：您使用了多少个平台、您对扩展流程的信任程度，以及您已经将凭证存放在何处。如果您大部分停留在某个单一OS生态系统内部（全Apple，或者全Windows），使用原生的平台身份验证器路径是最整洁的选择。在这种设置下，Brave的行为非常类似于Chrome或Safari。如果您需要通行密钥一致地跟随您跨越Windows、macOS、Linux和Android，像1Password、Bitwarden、Dashlane或Proton Pass等第三方密码管理器扩展仍然是唯一广泛可用的同步层。 并发症在于，自2024年4月起，不断有报告称原生通行密钥UI会断断续续地劫持扩展驱动的流程。[问题#37762](https://github.com/brave/brave-browser/issues/37762)中的用户描述了OS身份验证对话框出现，尽管Bitwarden或1Password应该拥有该凭证。到2026年3月，旧的解决办法（禁用`brave://flags/#web-authentication-new-passkey-ui`）不再可用，因为该标志已在版本146中被移除。 | 存储位置 | 跨OS同步 | 跨浏览器使用 | 恢复方式 | 已知风险 | | ----------------------- | ------------------ | ------------------- | --------------- | ---------------------------- | | iCloud钥匙串 | 仅限Apple | Apple浏览器 | Apple ID | 无 | | Windows Hello | 否（绑定到设备） | 同一台Windows设备 | 设备解锁 / PIN | 无法禁用Hello对话框 | | Google密码管理器 | GPM可用的地方 | Chrome + Android表面| Google帐户 | 未在此处的Brave配置文件中暴露| | 1Password / Bitwarden | 完全支持 | 完全支持（扩展） | 密码库帐户 | 间歇性的原生拦截 | | 硬件安全密钥 | 绑定到设备 | 任何浏览器 | 物理占有 | 无 | 在实践中，许多注重隐私的用户在2026年最终形成的模式是混合模式：在同一生态系统中的日常登录使用OS平台身份验证器，在跨平台可移植性很重要的地方使用密码管理器扩展，并为高价值账户保留一个硬件安全密钥。 ## 7. 在2026年用户正在报告哪些通行密钥痛点？ 2026年Brave未决的通行密钥问题聚集在三个反复出现的主题周围：扩展拦截、去Google化设备上的Android故障，以及桌面安全密钥问题。截至2026年4月，更广泛的存储库仍然显示24个匹配`webauthn`或`passkey`的未决问题，这表明摩擦是集中的，而非随机的。 最繁忙的集群是扩展拦截，原生通行密钥UI可以覆盖1Password、Bitwarden或Dashlane提示。没有Google Play服务的Android兼容性是第二个反复出现的问题，桌面安全密钥检测是第三个。此处最常被引用的问题主题是[`#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)和[`#51858`](https://github.com/brave/brave-browser/issues/51858)。活跃的帖子无需过多直接引用便都指向同一个方向。 这些问题中的几个在过去90天内收到了新评论，这使得它们成为活跃的退化而不是历史上的奇谈。对于构建通行密钥流程的开发人员来说，结论很明确：在Brave中明确测试由扩展驱动的流程，并在WebAuthn调用失败时提供明智的回退方案。对于用户而言，教训同样切合实际：在重要账户上配置硬件安全密钥或另一个恢复因素。 ## 8. 结论 Brave中的通行密钥故事在代码级别上很清晰，但在用户体验级别上很混乱。WebAuthn路径实际上是Chromium的，仅用一个字符串覆盖来确认实现与上游的紧密程度。在Apple平台上，由于iCloud钥匙串拥有凭证，因此通行密钥可移植性的表现与用户的预期完全一致。真正的摩擦在其他地方：扩展拦截（#37762）、Windows Hello抑制（#51858）和Android对Google Play服务的依赖（#45415）。在解决这些问题之前，开发人员应该单独测试Brave，而不是假设它等同于Chrome；而用户应该为重要帐户保持强大的回退选项——理想情况是硬件安全密钥。 ## 9. 关于Corbado Corbado为消费者登录构建通行密钥基础设施，并为需要大规模运行通行密钥和身份验证系统的团队提供通行密钥智能平台。我们基于实际部署、直接源检查和对底层规范的仔细阅读，发布对浏览器和操作系统的WebAuthn及通行密钥行为的技术分析。我们随时欢迎提出问题或指正。 ## 10. 常见问题解答 ### 10.1 在macOS的Brave浏览器中创建的通行密钥，可以在另一台Apple设备的Safari中使用吗？ 可以，但前提是Brave将通行密钥保存到iCloud钥匙串中。在macOS上，Brave使用Chromium的WebAuthn技术栈，可以在iCloud钥匙串中或创建提示中显示的另一个存储目标中存储新通行密钥。保存到iCloud钥匙串的通行密钥通过Apple ID同步，并可以在共享该Apple ID的Apple设备上的Safari、Chrome和其他浏览器中使用。保存到浏览器配置文件存储或仅限本地的存储的通行密钥不会自动在另一台Apple设备的Safari中变得可用。 ### 10.2 为什么在没有Google Play服务的Android上，Brave中的通行密钥会失败？ Brave在没有Google Play服务的情况下在Android上可能会失败，但原因比“凭据管理器是Play服务的一部分”更为具体。Android的凭据管理器是一个系统和Jetpack API，而较旧的Android版本更严重地依赖由Google Play服务支持的FIDO2层。在实践中，Brave仍然继承了`brave/brave-browser`问题#45415中记录的失败情况：在GrapheneOS、CalyxOS或其他没有所需Play服务路径的去Google化Android版本上，通行密钥对话框永远不会打开，注册或身份验证会超时。 有关更广泛的Android故障情况，请参阅原生应用通行密钥错误。有关Google Play服务和凭据管理器的具体信息，请参阅Android和Google Play服务通行密钥错误代码。 ### 10.3 Brave是否像Chrome一样跨设备同步通行密钥？ 不会。Brave没有提供等同于Chrome通过Google密码管理器实现的浏览器配置文件通行密钥同步功能。在Brave中创建的通行密钥存储在底层OS平台身份验证器中——Apple上的iCloud钥匙串、Windows上的Windows Hello以及Android上的Android凭据管理器——并仅通过该OS帐户进行同步。如果您希望拥有一致的跨设备同步，则需要依赖OS供应商或第三方密码管理器扩展。 ### 10.4 为什么即使我在设置中禁用了通行密钥选项，Brave仍会弹出Windows Hello通行密钥提示？ Brave的`brave://password-manager/settings`开关仅控制Brave本身是否提供保存通行密钥的选项。它不会阻止Windows向页面宣称Windows Hello是WebAuthn平台身份验证器。该网站调用WebAuthn，Windows展示Hello，而Brave没有浏览器内开关来抑制操作系统的对话框。此行为在`brave/brave-browser`问题#51858中被跟踪。 ### 10.5 我应该将通行密钥存储在Brave的原生流程中还是我的密码管理器中？ 如果您停留在一个生态系统内并且希望将活动组件降至最低，请使用Brave的原生OS流程（通过平台使用iCloud钥匙串或Google密码管理器）。如果您需要通行密钥在Windows、macOS、Linux和Android之间保持一致，或者如果您已经将秘密保存在那里，请使用如1Password或Bitwarden等第三方密码管理器扩展。由于2024年以来的Brave的原生UI多次拦截了扩展通行密钥流程，因此值得验证该扩展是否仍然拥有提示框。 ### 10.6 brave/brave-browser存储库目前有多少关于Brave通行密钥行为的未决问题？ 截至2026年4月，`brave/brave-browser`中包含24个与`passkey`或`WebAuthn`搜索匹配的未决问题。标记为通行密钥的未决问题从2022-2023年的每年约2个增长到了2025年的6个新开问题。对于Brave而言，主要的主题是桌面上的扩展拦截、Windows Hello抑制和Android Google Play服务依赖性。