bitwarden/browser
1
0
Fork 0
mirror of https://github.com/bitwarden/browser synced 2026-02-18 10:23:52 +00:00
Code Issues Releases Wiki Activity

Autofill Provider Readme Update (#18624)

Browse Source 
* Update the autofill provider readme

* Update casing based on pr suggestion
This commit is contained in:
Colton Hurst
2026-01-29 08:39:45 -05:00
committed by GitHub
parent 1db00097d2
commit 6d1693050c
1 changed files with 5 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
apps/desktop/desktop_native/autofill_provider/README.md
View File

@@ -2,11 +2,14 @@
A library for native autofill providers to interact with a host Bitwarden desktop app.
In this desktop context, "native autofill providers" are operating system frameworks or APIs (like the macOS [autofill framework](https://developer.apple.com/documentation/Security/password-autofill)) that allow Bitwarden to provide provide user credentials for things like autofill, passkey operations, etc.
# Explainer: Mac OS Native Passkey Provider
This document describes the changes introduced in https://github.com/bitwarden/clients/pull/13963, where we introduce the MacOS Native Passkey Provider. It gives the high level explanation of the architecture and some of the quirks and additional good to know context.
## The high level
MacOS has native APIs (similar to iOS) to allow Credential Managers to provide credentials to the MacOS autofill system (in the PR referenced above, we only provide passkeys).
We’ve written a Swift-based native autofill-extension. It’s bundled in the app-bundle in PlugIns, similar to the safari-extension.
@@ -16,7 +19,7 @@ This swift extension currently communicates with our Electron app through IPC ba
Footnotes:
* We're not using the IPC framework as the implementation pre-dates the IPC framework.
* Alternatives like XPC or CFMessagePort may have better support for when the app is sandboxed.
* Alternatives like XPC or CFMessagePort may have better support for when the app is sandboxed.
Electron receives the messages and passes it to Angular (through the electron-renderer event system).
@@ -26,7 +29,7 @@ Our existing fido2 services in the renderer respond to events, displaying UI as
We utilize the same FIDO2 implementation and interface that is already present for our browser authentication. It was designed by @coroiu with multiple ‘ui environments' in mind.
Therefore, a lot of the plumbing is implemented in /autofill/services/desktop-fido2-user-interface.service.ts, which implements the interface that our fido2 authenticator/client expects to drive UI related behaviors.
Therefore, a lot of the plumbing is implemented in /autofill/services/desktop-fido2-user-interface.service.ts, which implements the interface that our fido2 authenticator/client expects to drive UI related behaviors.
We’ve also implemented a couple FIDO2 UI components to handle registration/sign in flows, but also improved the “modal mode” of the desktop app.