Love the option to login/unlock with PRF supported passkey device (i.e. yubikey) and would love to see it make it to the chrome extension. I believe this is technically feasible, correct?
Any idea when we can expect to this awesome feature rolled out to more clients? Is there a prioritized list of them somewhere?
grb
April 20, 2025, 9:42pm
42
According to this recent comment from Bitwarden, expanded support for passkey login is being de-prioritized “for the immediate future”.
I don’t want my phone to be implicitly trusted any more than my PC is, however as I have a long master password, it’s really annoying to have to re-enter it every time I want to login to my vault on my phone.
Therefor, I would like to have the opportunity to allow my biometrics to be used in place of a master password when logging in on mobile. In order to maintain security, the app can re-prompt the master password if it sees that the biometrics for a device have been changed (i.e. New fingerprint added, or one removed)
@CodingCatAero Welcome to the forum!
I moved your post into this existing feature request to the same topic, as…
… that would be possible, if one could login to the BW mobile apps (or the other BW apps) with a passkey.
Thank you! As always, I did try searching for similar posts ^w^;
1 Like
The trick here is to keep your phone’s vault locked, instead of logging it out. Unlock with biometrics is available today.
1 Like
kezz
July 24, 2025, 2:45am
47
Yes I already searched, but it’s locked.
Should I be able to use PassKeys to authenticate my Bitwarden account with the Edge (or Chrome) browser extension ?
March 2024… “It’s coming”
Don’t hold your breath, folks.
Too much to ask to be able to log in with a passkey to the mobile apps as well?
Okay fine, just the extension.
Awesome. Thanks.
@kezz I moved your post into an existing feature request to the same topic.
… I just saw some movement here (but no idea of any timelines!):
main ← anders/browser-prf
opened 07:32PM - 11 Sep 25 UTC
## 🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-13632
## 📔 Ob… jective
This PR adds "Sign in with passkeys" UI to the browser extension. It's dependent on https://github.com/bitwarden/server/pull/6317 to work.
## 📸 Screenshots
Demo video: https://share.cleanshot.com/93P7RsmJ
<img width="410" height="621" alt="CleanShot 2025-09-11 at 21 36 45@2x" src="https://github.com/user-attachments/assets/d7bb789a-a6cd-4a94-823e-4b698382920e" />
<img width="410" height="621" alt="image" src="https://github.com/user-attachments/assets/9c74c18c-a925-4b70-9181-5917fa649e47" />
<img width="388" height="612" alt="image" src="https://github.com/user-attachments/assets/d4b88449-a7af-41c6-b8b8-c85f5a57e548" />
## ⏰ Reminders before review
- Contributor guidelines followed
- All formatters and local linters executed and passed
- Written new unit and / or integration tests where applicable
- Protected functional changes with optionality (feature flags)
- Used internationalization (i18n) for all UI strings
- CI builds passed
- Communicated to DevOps any deployment requirements
- Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team
## 🦮 Reviewer guidelines
- 👍 (`:+1:`) or similar for great changes
- 📝 (`:memo:`) or ℹ️ (`:information_source:`) for notes or general info
- ❓ (`:question:`) for questions
- 🤔 (`:thinking:`) or 💭 (`:thought_balloon:`) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
- 🎨 (`:art:`) for suggestions / improvements
- ❌ (`:x:`) or ⚠️ (`:warning:`) for more significant problems or concerns needing attention
- 🌱 (`:seedling:`) or ♻️ (`:recycle:`) for future improvements or indications of technical debt
- ⛏ (`:pick:`) for minor or nitpick changes
PS: … dependent on:
main ← anders/configurable-fido2-origins
opened 07:04PM - 11 Sep 25 UTC
## 🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-13632
## 📔 Ob… jective
This PR contains enablement work for the browser extension work, tracked by https://bitwarden.atlassian.net/browse/PM-13632.
It enables us to configure multiple allowed origins, so that we can list our domain (https://bitwarden.com etc) as well as our browser extension (chrome-extension://aabbbccc).
It loads additional Origins from the configuraiton to allow us to update it dynamically or use different values in different environments.
## 📸 Screenshots
## ⏰ Reminders before review
- Contributor guidelines followed
- All formatters and local linters executed and passed
- Written new unit and / or integration tests where applicable
- Protected functional changes with optionality (feature flags)
- Used internationalization (i18n) for all UI strings
- CI builds passed
- Communicated to DevOps any deployment requirements
- Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team
## 🦮 Reviewer guidelines
- 👍 (`:+1:`) or similar for great changes
- 📝 (`:memo:`) or ℹ️ (`:information_source:`) for notes or general info
- ❓ (`:question:`) for questions
- 🤔 (`:thinking:`) or 💭 (`:thought_balloon:`) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
- 🎨 (`:art:`) for suggestions / improvements
- ❌ (`:x:`) or ⚠️ (`:warning:`) for more significant problems or concerns needing attention
- 🌱 (`:seedling:`) or ♻️ (`:recycle:`) for future improvements or indications of technical debt
- ⛏ (`:pick:`) for minor or nitpick changes
3 Likes
Be.ing
September 11, 2025, 9:45pm
51
Based on the screen recording in the pull request, it does seem to be true!
Be.ing
September 11, 2025, 10:27pm
52
Unfortunately only Chromium and derivative browsers can support this currently. Tracking issue for Firefox:
W3C WebExtensions discussion:
opened 05:10PM - 07 Jul 22 UTC
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.
2 Likes
Found in the version 2025.11.0 release notes …
Log in with passkey support on browser extensions : Users can now log in to browser extensions with a passkey . Currently, Chrome and Chromium-based browsers like Edge are supported.
2 Likes
Be.ing
November 12, 2025, 10:04pm
54
Implementation of this in Firefox has begun but seems to be blocked on clarification of how to handle that W3C issue
1 Like
Preparations for passkey login for the desktop app (“passkey unlock” is also already mentioned there):
main ← km/fido2-desktop-plumbing
opened 12:49PM - 17 Nov 25 UTC
## 🎟️ Tracking
## 📔 Objective
Electron does not support PRF unlock a… nd has no plans to do so. Therefore, to implement unlock with PRF, we need to use `desktop_native`. The simplest way to do so, is to move calls to the navigatorCredetials functions into a service, and on desktop route these through to `main` and then `desktop_native` so that we can use native functions implementing support.
This PR adds support for navigator credentials in `desktop_native`. Currently, the only implementation currently is for security keys via the `ctap-hid-fido2` crate as an example implementation. This implementation is gated behind a compile-time feature flag. The intent is to - for mac and windows - use the platform's native APIs to be able to use all authenticator types, not just security keys, before enabling support for these platforms.
### Windows / Mac support
To support windows / mac's native APIs, all that needs to be done is implement a single file in `desktop_native/fido2_client`. For windows, the `windows-rs` crate can be directly used. For mac, `swift-rs` + a swift module is a possible path. That is not done within this PR!
## 📸 Screenshots
https://github.com/user-attachments/assets/07734957-7b43-4bcd-af8f-2eadc2b4c160
https://github.com/user-attachments/assets/72fe6098-f208-43b0-805b-1af3b2612b62
## ⏰ Reminders before review
- Contributor guidelines followed
- All formatters and local linters executed and passed
- Written new unit and / or integration tests where applicable
- Protected functional changes with optionality (feature flags)
- Used internationalization (i18n) for all UI strings
- CI builds passed
- Communicated to DevOps any deployment requirements
- Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team
## 🦮 Reviewer guidelines
- 👍 (`:+1:`) or similar for great changes
- 📝 (`:memo:`) or ℹ️ (`:information_source:`) for notes or general info
- ❓ (`:question:`) for questions
- 🤔 (`:thinking:`) or 💭 (`:thought_balloon:`) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
- 🎨 (`:art:`) for suggestions / improvements
- ❌ (`:x:`) or ⚠️ (`:warning:`) for more significant problems or concerns needing attention
- 🌱 (`:seedling:`) or ♻️ (`:recycle:`) for future improvements or indications of technical debt
- ⛏ (`:pick:`) for minor or nitpick changes
grb
November 19, 2025, 1:58pm
56
I’m hoping that passkey login also gets implemented for Safari extensions (and for the macOS Desktop app) in the not too distant future, and wonder what the prospects for this are. Are there any known technical hurdles?
From that PR:
It’s a bit strange, that the title and videos speak of “login”, but the text speaks of “PRF unlock” – but either way, it seems Mac support is on the radar.
1 Like
Be.ing
November 19, 2025, 3:08pm
58
That depends on Safari implementing both Webauthn PRF and a means for the browser extension to associate a passkey with a different domain than where it is used (use bitwarden.com passkey within the extension when the extension’s pages are not bitwarden.com ).
I just found an overview from Yubico: Developers Guide to PRF → scroll down to the section " Navigating Platform Support and Incompatibilities"
According to this, and if it didn’t change the last months/weeks, it seems Safari on MacOS lacks the possibility to make use of “roaming authenticators” (e.g. YubiKeys) – though I’m not sure if “entirely” or only regarding PRF?!
PS: Here is a similar overview.
grb
November 20, 2025, 3:55pm
60
Thanks. It seems that macOS/Safari does have the ability to support passkeys stored in the Apple keychain, just not passkeys stored on hardware keys.
1 Like
