1Password SDK local integration security
1Password SDKs allow you to build integrations between 1Password and other local applications and scripts that authenticate using authorization prompts from the 1Password desktop app on the user's device. Authorization prompts clearly detail the process that's requesting access, which account the process will access, and the scope and duration of that access. Users must approve the request using the same method they use to unlock their 1Password app, like with biometrics or their 1Password account password. The credential used to authenticate never leaves the 1Password app process.
To learn about the security model for automated access, see our 1Password Service Account security model. For information about 1Password security practices, visit the 1Password Security homepage.
Security model
Local 1Password desktop app integrations rely on a human-in-the-loop authorization model. When the integration makes a request, the 1Password desktop app prompts the user to authorize the request the same way they unlock their 1Password account in the app, like with Touch ID, Windows Hello, system authentication, or their 1Password account password. After the user grants the integration access, the SDK can then send requests to 1Password, which provides responses until access expires.
Local integrations can only access 1Password after a user provides explicit authorization. To enforce this, 1Password serves the user an authorization prompt that contains the name of the 1Password account where access is requested (for example, AgileBits or Wendy Appleseed's Family) and the process requesting access, as well as the scope and duration of access that the process will receive. The user must approve the prompt for the integration to be granted access to the account.
After access is granted, authorization is time-bound to ten minutes of inactivity, limited to the approved account and process, and expires if the user locks their 1Password account in the app.
Authorization model
Authorization occurs on a per-account and per-process basis. If the user is signed in to multiple accounts, each account must be authorized separately. If the user runs multiple integrations, each process must be authorized separately.
Authorization expires after ten minutes of inactivity, after which the user must re-authorize. Authorization also expires if the user locks their account in the 1Password desktop app.
Technical design
Communication
After a user turns on the option to integrate with SDKs in the 1Password desktop app, the 1Password app spawns a platform-native Inter-Process Communication (IPC) channel – Mach ports on Mac, named pipes on Windows, and Unix domain sockets on Linux – to listen for incoming connections. These channels create a direct, local connection that cannot be hijacked or redirected once established.
When a new process connects to the channel through the SDKs, the 1Password desktop app prompts the user for authorization using the same method they use to unlock the app. The user must explicitly approve the prompt with biometrics, their 1Password account password, or their identity provider before any sensitive data is exchanged.
Process identification
When a process using the SDK connects to the secure communication channel, the 1Password desktop app retrieves the Process ID (PID) of the caller. The PID is used to query the operating system for the executable's name and its absolute path on the file system.
Because integrations are built by third parties, the 1Password app cannot verify a 1Password-issued code signature for these binaries. Instead, the app presents the discovered app name to the user in an authorization prompt. The user acts as the final validator, which makes sure that the application requesting access is the one they intended to run.
Authorization and session persistence
Authorization is granted on a per-process basis. A single approval grants the specific process access to the authorized 1Password account for a limited duration of up to ten minutes of inactivity. If the account in the 1Password app is locked, all existing SDK authorizations are immediately revoked.
Accepted risks
- A user or application with root or administrator-level privileges on the same system may be able to circumvent one or more security measures and could obtain access to 1Password accounts.
- Users of integrations must trust that the integration is not malicious. If a user knowingly installs a malicious application and grants it access to their account, the SDK will fulfill its function and provide the requested data to the application.
- The SDK relies on the integrity of the local 1Password desktop application. If an attacker replaces the legitimate 1Password app with a malicious impersonator, the SDK may inadvertently transmit newly created items or secrets directly to the attacker’s application.