Sign into Bitwarden with a passkey / "Login with passkeys" (for all BW apps)

Be.ing · September 11, 2025, 10:27pm

Unfortunately only Chromium and derivative browsers can support this currently. Tracking issue for Firefox:

W3C WebExtensions discussion:

github.com/w3c/webextensions

WebExtensions should use asset links model for WebAuthn RP ID

opened 05:10PM - 07 Jul 22 UTC

timcappalli

proposal

Original issue created by @Mikescops is here: https://github.com/w3c/webauthn/is…sues/1766 I believe this would be net new for the Web Extensions area. I don't think there is anything specific to change in WebAuthn. EDIT: Adding additional details WebAuthn credentials are origin-bound. For example, a credential created for login.example.com cannot be used by contoso.com. This is one of the primary security properties that enable phishing resistance. Using a WebAuthn credential in the native app world can be challenging as apps do not use web origins for their identity. Example Co's app may have an app identifier of `com.example.app.android.prod`. This has been addressed by platform vendors by using "asset links"[1] / "associated domains"[2] where an app developer can link their app to their web origin. Most password managers today use some kind of knowledge factor / secret for signing into the password manager and for some unlock operations. Many password managers would like to move to stronger, phishing-resistant auth. Browser extensions have a similar problem as mobile apps, except in this case, there is a web origin, but it is locally-specific to the extension. For example, Bitwarden in Edge is: `edge-extension://jbkfoedolllekgbhcbcoahefnbanhhlh` and in Chrome is `chrome-extension://jbkfoedolllekgbhcbcoahefnbanhhlh`. The browser / platform will never allow a WebAuthn credential for `vault.bitwarden.com` to be used to for those extensions because of this mismatch, by design. **The formal ask is to evaluate an asset-links style model for web extensions that allow a formal link back to the primary web origin.** [1] https://developers.google.com/identity/fido/android/native-apps#interoperability_with_your_website [2] https://developer.apple.com/documentation/xcode/supporting-associated-domains

From a quick search for “relying party” on the WebKit issue tracker, it doesn’t seem anyone has opened an issue there yet.