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

Nail1684 · November 21, 2025, 12:56pm

… ah, and PRF support seems to be missing completely for Safari as @Be.ing already ~~wrote~~ implied:

WebAuthn PRF extension

opened 10:22PM - 04 May 23 UTC

topic: authentication venue: W3C Web Authentication WG

### WebKittens @pascoej ### Title of the spec WebAuthn PRF extension ### URL… to the spec https://w3c.github.io/webauthn/#prf-extension ### URL to the spec's repository https://github.com/w3c/webauthn ### Issue Tracker URL _No response_ ### Explainer URL https://github.com/w3c/webauthn/wiki/Explainer:-PRF-extension ### TAG Design Review URL https://github.com/w3ctag/design-reviews/issues/806 ### Mozilla standards-positions issue URL https://github.com/mozilla/standards-positions/issues/798 ### WebKit Bugzilla URL _No response_ ### Radar URL _No response_ ### Description (Requested as part of https://groups.google.com/a/chromium.org/g/blink-dev/c/iTNOgLwD2bI)

PS:

I think you mean the “Related Origins Request” (ROR) … that seems to be implemented since Safari 18: Safari 18.0 Release Notes | Apple Developer Documentation – and one can also see that here (there, one can also see that ROR is a stopper for the Firefox extension)

grb · November 21, 2025, 3:43pm

Yet, Section 5.1.2 of the Corbado blog article plainly states that (as of macOS 15) “both Safari and Chrome support PRF via iCloud Keychain.”…

grb · December 13, 2025, 2:42am

A post was merged into an existing topic: Unlock with FIDO2/“passkeys”

improg · February 10, 2026, 9:28am

Good day. Is it planned to add a passwordless login to mobile devices using yubikey? My wife is interested in using Bitwarden on her iphone, but she can’t remember anything more complicated that her name. And a computer is not always accessible to use “login with device”, like it is realized now. Using yubikey seems to be good alternative, more secure, than face id.

Nail1684 · February 20, 2026, 12:19pm

Hm. It looks like PRF might have been implemented in last November for Safari:

github.com/WebKit/WebKit

[WebAuthn] Implement PRF extension + hmac-secret (#53734)

main ← pascoej:eng/WebAuthn-Implement-PRF-extension-hmac-secret

opened 08:26AM - 11 Nov 25 UTC

pascoej

+948 -94

#### a305a458493c0d4b7835f5fee17cc70295221d38 <pre> [WebAuthn] Implement PRF ext…ension + hmac-secret <a href="https://rdar.apple.com/113572812">rdar://113572812</a> <a href="https://bugs.webkit.org/show_bug.cgi?id=259934">https://bugs.webkit.org/show_bug.cgi?id=259934</a> Reviewed by Brent Fulgham. Implements the PRF extension for WebAuthn to enable deriving cryptographic secrets from credentials. The prf extension maps to the CTAP hmac-secret extension, supporting both credential creation and authentication flows with salt evaluation. This enables use cases like credential-bound encrypted storage. Tests: Tools/TestWebKitAPI/Tests/WebCore/CtapPinTest.cpp Tools/TestWebKitAPI/Tests/WebCore/CtapRequestTest.cpp Tools/TestWebKitAPI/Tests/WebCore/CtapResponseTest.cpp Tools/TestWebKitAPI/Tests/WebCore/FidoTestData.h * LayoutTests/http/wpt/webauthn/public-key-credential-create-success-hid.https-expected.txt: * LayoutTests/http/wpt/webauthn/public-key-credential-create-success-hid.https.html: * LayoutTests/http/wpt/webauthn/public-key-credential-get-success-hid.https-expected.txt: * LayoutTests/http/wpt/webauthn/public-key-credential-get-success-hid.https.html: * LayoutTests/http/wpt/webauthn/resources/util.js: * Source/WebCore/Modules/webauthn/AuthenticatorAssertionResponse.cpp: (WebCore::AuthenticatorAssertionResponse::create): * Source/WebCore/Modules/webauthn/AuthenticatorAssertionResponse.h: * Source/WebCore/Modules/webauthn/AuthenticatorAttestationResponse.cpp: (WebCore::AuthenticatorAttestationResponse::create): * Source/WebCore/Modules/webauthn/AuthenticatorAttestationResponse.h: * Source/WebCore/Modules/webauthn/AuthenticatorResponse.cpp: (WebCore::AuthenticatorResponse::extensions const): * Source/WebCore/Modules/webauthn/cbor/CBORReader.cpp: (cbor::CBORReader::readWithBytesConsumed): * Source/WebCore/Modules/webauthn/cbor/CBORReader.h: * Source/WebCore/Modules/webauthn/fido/DeviceRequestConverter.cpp: (fido::encodeMakeCredentialRequestAsCBOR): (fido::encodeGetAssertionRequestAsCBOR): * Source/WebCore/Modules/webauthn/fido/DeviceRequestConverter.h: * Source/WebCore/Modules/webauthn/fido/DeviceResponseConverter.cpp: (fido::parseAuthenticatorDataExtensions): (fido::readCTAPMakeCredentialResponse): (fido::readCTAPGetAssertionResponse): * Source/WebCore/Modules/webauthn/fido/FidoConstants.h: * Source/WebCore/Modules/webauthn/fido/Pin.cpp: (fido::pin::decryptForProtocol): (fido::pin::TokenResponse::parse): (fido::pin::HmacSecretRequest::HmacSecretRequest): (fido::pin::HmacSecretRequest::create): (fido::pin::HmacSecretResponse::HmacSecretResponse): (fido::pin::HmacSecretResponse::parse): (fido::pin::HmacSecretResponse::output const): * Source/WebCore/Modules/webauthn/fido/Pin.h: (fido::pin::HmacSecretRequest::sharedKey const): (fido::pin::HmacSecretRequest::coseKey const): (fido::pin::HmacSecretRequest::saltEnc const): (fido::pin::HmacSecretRequest::saltAuth const): (fido::pin::HmacSecretRequest::protocol const): * Source/WebKit/UIProcess/API/Cocoa/_WKAuthenticationExtensionsClientInputs.h: * Source/WebKit/UIProcess/API/Cocoa/_WKAuthenticationExtensionsClientInputs.mm: (-[_WKAuthenticationExtensionsClientInputs dealloc]): * Source/WebKit/UIProcess/API/Cocoa/_WKAuthenticationExtensionsClientOutputs.h: * Source/WebKit/UIProcess/API/Cocoa/_WKAuthenticationExtensionsClientOutputs.mm: (-[_WKAuthenticationExtensionsClientOutputs initWithAppid:]): (-[_WKAuthenticationExtensionsClientOutputs initWithAppid:prfEnabled:prfFirst:prfSecond:]): (-[_WKAuthenticationExtensionsClientOutputs prfFirst]): (-[_WKAuthenticationExtensionsClientOutputs prfSecond]): * Source/WebKit/UIProcess/API/Cocoa/_WKAuthenticationExtensionsClientOutputsInternal.h: * Source/WebKit/UIProcess/API/Cocoa/_WKWebAuthenticationPanel.mm: (authenticationExtensionsClientInputs): * Source/WebKit/UIProcess/WebAuthentication/fido/CtapAuthenticator.cpp: (WebKit::CtapAuthenticator::continueMakeCredentialAfterCheckExcludedCredentials): (WebKit::CtapAuthenticator::continueGetAssertionAfterCheckAllowCredentials): * Source/WebKit/UIProcess/WebAuthentication/fido/CtapAuthenticator.h: * Tools/TestWebKitAPI/Tests/WebCore/CtapPinTest.cpp: (TestWebKitAPI::TEST(CtapPinTest, TestHmacSecretRequestCreate)): (TestWebKitAPI::TEST(CtapPinTest, TestHmacSecretRequestInvalidSalts)): (TestWebKitAPI::TEST(CtapPinTest, TestHmacSecretResponseRoundTrip)): (TestWebKitAPI::TEST(CtapPinTest, TestHmacSecretResponseInvalidSize)): * Tools/TestWebKitAPI/Tests/WebCore/CtapRequestTest.cpp: (TestWebKitAPI::TEST(CTAPRequestTest, TestConstructMakeCredentialRequestWithHmacSecret)): (TestWebKitAPI::TEST(CTAPRequestTest, TestConstructGetAssertionRequestWithHmacSecret)): * Tools/TestWebKitAPI/Tests/WebCore/CtapResponseTest.cpp: (TestWebKitAPI::TEST(CTAPResponseTest, TestReadMakeCredentialResponseWithHmacSecret)): (TestWebKitAPI::TEST(CTAPResponseTest, TestReadGetAssertionResponseWithHmacSecret)): (TestWebKitAPI::TEST(CTAPResponseTest, TestReadGetAssertionResponseWithHmacSecret64)): * Tools/TestWebKitAPI/Tests/WebCore/FidoTestData.h: (TestWebKitAPI::TestData::std::to_array<uint8_t>): Canonical link: <a href="https://commits.webkit.org/303406@main">https://commits.webkit.org/303406@main</a> </pre> https://github.com/WebKit/WebKit/commit/6903d94ffc4654b85b8b212198d4cc41920327ea | Misc | iOS, visionOS, tvOS & watchOS | macOS | Linux | Windows | Apple Internal | | ----- | ---------------------- | ------- | ----- | --------- | ------ | | [✅ 🧪 style](https://ews-build.webkit.org/#/builders/38/builds/132207 "Passed style check") | [✅ 🛠 ios](https://ews-build.webkit.org/#/builders/159/builds/4700 "Built successfully") | [✅ 🛠 mac](https://ews-build.webkit.org/#/builders/138/builds/43235 "Built successfully") | [✅ 🛠 wpe](https://ews-build.webkit.org/#/builders/5/builds/139722 "Built successfully") | [✅ 🛠 win](https://ews-build.webkit.org/#/builders/59/builds/84132 "Built successfully") | ⏳ 🛠 ios-apple | [✅ 🧪 bindings](https://ews-build.webkit.org/#/builders/9/builds/134077 "Passed tests") | [✅ 🛠 ios-sim](https://ews-build.webkit.org/#/builders/155/builds/4731 "Built successfully") | [✅ 🛠 mac-AS-debug](https://ews-build.webkit.org/#/builders/156/builds/4461 "Built successfully") | [✅ 🧪 wpe-wk2](https://ews-build.webkit.org/#/builders/34/builds/101054 "Passed tests") | [✅ 🧪 win-tests](https://ews-build.webkit.org/#/builders/60/builds/68376 "Passed tests") | ⏳ 🛠 mac-apple | [✅ 🧪 webkitperl](https://ews-build.webkit.org/#/builders/11/builds/135153 "Passed tests") | [ ~~🧪 ios-wk2~~](https://ews-build.webkit.org/#/builders/162/builds/3345 "The change is no longer eligible for processing. Pull Request was already closed when EWS attempted to process it.") | [✅ 🧪 api-mac](https://ews-build.webkit.org/#/builders/18/builds/118420 "Passed tests") | [✅ 🧪 api-wpe](https://ews-build.webkit.org/#/builders/41/builds/81849 "Passed tests") | | ⏳ 🛠 vision-apple | | [ ~~🧪 ios-wk2-wpt~~](https://ews-build.webkit.org/#/builders/154/builds/3228 "The change is no longer eligible for processing. Pull Request was already closed when EWS attempted to process it.") | [ ~~🧪 api-mac-debug~~](https://ews-build.webkit.org/#/builders/165/builds/1077 "The change is no longer eligible for processing. Pull Request was already closed when EWS attempted to process it.") | [✅ 🛠 wpe-cairo](https://ews-build.webkit.org/#/builders/65/builds/82942 "Built successfully") | | | | [✅ 🧪 api-ios](https://ews-build.webkit.org/#/builders/13/builds/112049 "Passed tests") | [✅ 🧪 mac-wk1](https://ews-build.webkit.org/#/builders/135/builds/36538 "Passed tests") | [✅ 🛠 gtk](https://ews-build.webkit.org/#/builders/2/builds/142369 "Built successfully") | | | | [✅ 🛠 vision](https://ews-build.webkit.org/#/builders/153/builds/4369 "Built successfully") | [✅ 🧪 mac-wk2](https://ews-build.webkit.org/#/builders/136/builds/37119 "Passed tests") | [✅ 🧪 gtk-wk2](https://ews-build.webkit.org/#/builders/1/builds/109432 "Passed tests") | | | | [✅ 🛠 vision-sim](https://ews-build.webkit.org/#/builders/160/builds/4450 "Built successfully") | [✅ 🧪 mac-AS-debug-wk2](https://ews-build.webkit.org/#/builders/161/builds/3780 "Passed tests") | [✅ 🧪 api-gtk](https://ews-build.webkit.org/#/builders/21/builds/109613 "Passed tests") | | | [✅ 🛠 🧪 merge](https://ews-build.webkit.org/#/builders/19/builds/27793 "Built successfully and passed tests") | [✅ 🧪 vision-wk2](https://ews-build.webkit.org/#/builders/164/builds/3310 "Passed tests") | [✅ 🧪 mac-wk2-stress](https://ews-build.webkit.org/#/builders/8/builds/114692 "Passed tests") | [✅ 🛠 playstation](https://ews-build.webkit.org/#/builders/134/builds/57616 "Built successfully") | | | | [✅ 🛠 tv](https://ews-build.webkit.org/#/builders/158/builds/4423 "Built successfully") | [✅ 🧪 mac-intel-wk2](https://ews-build.webkit.org/#/builders/137/builds/33070 "Passed tests") | | | | | [✅ 🛠 tv-sim](https://ews-build.webkit.org/#/builders/157/builds/4255 "Built successfully") | [✅ 🛠 mac-safer-cpp](https://ews-build.webkit.org/#/builders/120/builds/67869 "Built successfully") | | | | | [✅ 🛠 watch](https://ews-build.webkit.org/#/builders/163/builds/4514 "Built successfully") | | | | | | [✅ 🛠 watch-sim](https://ews-build.webkit.org/#/builders/152/builds/4382 "Built successfully") | | | |

tomillr · February 20, 2026, 12:09pm

Since Safari on macOS has added PRF support over a year ago, I’d like to know if the Bitwarden browser extension finally supports passwordless login? The documentation still states that only Chromium-based browsers are supported. It that still accurate? Any timeframe when support for Sarafi is going to be implemented?

Nail1684 · February 20, 2026, 12:22pm

@tomillr I moved your post into the relevant feature request for this.

If you look at the posts above, maybe one of the last “blockers” might be that – according to this overview from Corbado – the Safari extension still couldn’t make use of PRF-passkeys stored on security keys.

grb · February 20, 2026, 1:06pm

According to MDN browser-compat-data, Safari still does not support get() for the PRF extension, and they cite the following bug report thread as a source:

bcfp · February 21, 2026, 9:24am

On the positive side, the source indicates that Android has sufficient support for at least Yubikey. Are there other blocking issues for Android? (The FR subject says “for all BW apps”, so I assume this includes the Android mobile platform).

Neuron5569 · March 5, 2026, 8:54pm

Just a possibly related note, it seems to have been stated that Firefox 150 may support some additional passkey features that may allow this functionality (and also PRF unlock):

Since “Craig Lurey,” a possible CTO from Keeper, thinks this “bug” fix is necessary for passkey login, this may be the bug to track. Unfortunately, there is also another filed bug that directly specifies related origins request (ROR).

Be.ing · March 19, 2026, 9:31pm

That has now been implemented in Firefox!

Nail1684 · March 19, 2026, 11:06pm

@Be.ing That certainly is a step forward for Firefox – but I tend to aggree with @Neuron5569 that this is still an open issue now:

(and actually, I think “iinuwa” might be a BW developer)

fersingb · April 23, 2026, 6:56pm

It looks like the feature is now available in Firefox 150 ( Firefox 150 release notes for developers (Stable) - Mozilla | MDN ), let’s hope the Firefox extension will implement the feature soon.

Neuron5569 · May 9, 2026, 10:27am

It looks like the Related Origins issue has been fixed and closed and is aimed for Firefox 152.

So the schedule for the Firefox releases are:

Firefox 152: By June 16
Firefox 153.0esr: July 17

ahmet_of_luxembourg · June 21, 2026, 5:35pm

Issue has been resolved on the Firefox side; for version 152. Will the extension work out of box; then?

Nail1684 · June 21, 2026, 6:53pm

@ahmet_of_luxembourg Welcome to the forum!

Well, doesn’t look like it!

Neuron5569 · June 21, 2026, 9:22pm

Although I must say, because Bitwarden’s doc doesn’t explicitly exclude Firefox, and Firefox appears to have the necessary technical infrastructure, this unavailability can probably be considered a bug.

Nail1684 · June 21, 2026, 9:36pm

What?

I don’t think so… https://www.youtube.com/watch?v=PgiKKzkUCbg&t=2476s sounded like it has to be added to the Firefox extension…

Neuron5569 · June 22, 2026, 10:49pm

A bug has been filed:

github.com/bitwarden/clients

Passkey gate's cited Firefox blocker is fixed (FF 150)

opened 07:17PM - 22 Jun 26 UTC

Cwooper

bug browser

### Steps To Reproduce 1. Use Firefox 150+ (I tested 152). The relevant platfor…m fix is bugzilla 1956484 (allow extensions to assert a WebAuthn RP ID for a domain they have host permissions for), RESOLVED FIXED in FF 150. 2. Enroll a PRF-capable "log in with passkey" credential with vault encryption on your account (web vault -> "Log in with passkey"). 3. Open the Bitwarden Firefox extension. Look for "log in with passkey" on the login screen and "unlock with passkey" on the lock screen. 4. To confirm the platform capability directly: load a minimal MV3 extension with `host_permissions` for some domain, and from its popup call `navigator.credentials.create`/`get` with that domain as a foreign RP ID plus the `prf` extension. ### Expected Result Because FF 150 fixed the RP ID override the code cites (bugzilla 1956484, RESOLVED FIXED), the Firefox extension should offer passkey unlock -- and login -- like Chromium. I verified the platform supports it on FF 152 (see Testing below). Unlock in particular is a local, on-device operation and should work as soon as the Chromium-only gate is lifted. ### Actual Result Both options are hidden on Firefox, gated by two `isChromium()` checks whose comments cite the now-fixed limitation: 1. **Unlock**: `libs/key-management-ui/src/lock/services/default-webauthn-prf-unlock.service.ts`, `isPrfUnlockAvailable()`: ```ts if (clientType === ClientType.Browser && !this.platformUtilsService.isChromium()) { return false; } ``` 2. **Login**: `apps/browser/src/auth/popup/login/extension-login-component.service.ts`, `isLoginWithPasskeySupported()`: ```ts // Neither Firefox nor safari support overriding the relying party ID in an extension. // https://github.com/w3c/webextensions/issues/238 isLoginWithPasskeySupported(): boolean { return this.platformUtilsService.isChromium(); } ``` Unlock is hidden even though it would work locally. Login is hidden, and with the gate removed it additionally fails server-side with `invalid_grant` (400) -- see Client- vs server-side below. ### Additional Context #### Testing Note: tested on Firefox 152, Fedora, YubiKey 5C Nano Minimal throwaway MV3 extension, `host_permissions: ["*://example.com/*"]`, WebAuthn called from the popup: - Registered a PRF credential for `example.com` (a foreign RP ID, only granted via host permissions) -> `prf.enabled = true`. - Asserted from the `moz-extension://` origin with `prf.eval` -> got a 32-byte `prf.results.first`, no `SecurityError`. For comparison, the same key on a normal `localhost` page also returns PRF, so the key + Firefox security-key path is fine. I then built this repo with both gates opened for Firefox and loaded it as a temporary add-on (FF 152, MV3). The "Log in with passkey" button shows up and the WebAuthn assertion runs (PIN + tap), confirming the client side works. #### Client- vs server-side These behave differently and I think it's worth noting/treating them separately: - **Client-side unlock is local and shippable.** `unlockVaultWithPrf()` does a PRF assertion and decrypts the user key on-device -- it never calls the identity server. The PRF options come from sync (`default-sync.service.ts`), not from the login method, so a normal master-password login + sync populates them. With gate #1 removed this should work e2e on Firefox using only the FF 150 capability above. - **Login hits a server-side wall.** Passwordless login (`webauthn-login.service.ts`) asserts directly from the extension window, so `clientDataJSON.origin` is `moz-extension://<uuid>`. Logging in this way fails with `invalid_grant` (400); the origin looks like the cause, since the same flow on the web vault succeeds with origin `https://vault.bitwarden.com`. Chromium presumably works because its `chrome-extension://<id>` origin is stable and can be allowlisted server-side; **Firefox extension origins are a random per-install UUID**, so there's nothing stable to allowlist. Enabling login on Firefox needs a server change (or routing the assertion through a web-vault-origin connector, like the 2FA path already does via `webauthn-iframe.ts`). PR #16385 already depended on [bitwarden/server#6317](https://github.com/bitwarden/server/pull/6317), so the server component is a known part of this feature. #### Suggested fix/change - For unlock: replace the blanket `isChromium()` exclusion with a Firefox version floor (e.g. `isFirefox() && firefoxVersion >= 150`). There's no `firefoxVersion()` helper today, but there's precedent -- `safariVersion()` and the Safari version gate in `browser-platform-utils.service.ts`. - For login: same client gate, but only once the server accepts the Firefox extension origin (or the assertion is routed through a vault-origin connector). Happy to open a PR for the unlock path if that's a useful scope. BTW, this is the vault-encryption path, so I assume it wants a maintainer to bless the scope first. #### References - Firefox bug (the cited blocker, now fixed): https://bugzilla.mozilla.org/show_bug.cgi?id=1956484 - WebExtensions spec issue referenced in the code: https://github.com/w3c/webextensions/issues/238 - Chromium implementation (added the gate, depends on server#6317): https://github.com/bitwarden/clients/pull/16385 - Prior report (closed, pre-FF150): https://github.com/bitwarden/clients/issues/13945 - Mozilla FF 149-152 WebExtensions changes: https://blog.mozilla.org/addons/2026/04/23/webextensions-api-changes-firefox-149-152/ ### Screenshots or Videos _No response_ ### Additional Context _No response_ ### Operating System Linux ### Operating System Version Fedora 44 ### Web Browser Firefox ### Browser Version All ### Environment Versions Version: 2026.6.0 SDK: 'main (fdf056a)' Server version: 2026.6.0 ### Issue Tracking Info - [x] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

Nail1684 · June 23, 2026, 9:17am

That report was closed. – @Micah_Edelblut wrote there, that another Firefox bug has to be fixed before this feature can be implemented.