With 1Password Business and 1Password Unlock with SSO, you can bring single sign-on (SSO) authentication to your team. When performing a risk assessment, businesses that choose to use Unlock with SSO should consider how its security model and risk considerations differ from 1Password’s standard unlock model. Those considerations are outlined below.
Security model
Unlock with SSO allows team members to sign in to their 1Password Business account with the username and password associated with their identity provider instead of an account password and Secret Key. Only one identity provider can be active at a time. There are different risk considerations when using Unlock with SSO instead of the standard unlock method.
Unlock with SSO acts as an additional layer of identity proofing on top of the existing 1Password security model. The traditional 1Password security model includes using an account password and Secret Key to access and unlock your account. The account password is a secret that you remember and should only be stored in your brain.
Unlock with SSO works differently. 1Password confirms that a team member has authenticated to their identity provider, then downloads the team member’s encrypted credentials. The team member’s device key, stored on each device set to Unlock with SSO, is used to decrypt the credentials and access their 1Password data. When this process is complete, Unlock with SSO works just like 1Password with traditional unlock.
Different risk considerations
| Sign in to 1Password | Unlock offline | |
|---|---|---|
| Traditional unlock | Use your sign-in address, email address, Secret Key, and account password. A one-time password is required if your team uses two-factor authentication. Your device stores your Secret Key obfuscated on-disk. | An encrypted version of your 1Password data is stored locally and accessible with your account password. |
| Devices with strong platform key management (iOS, macOS, Android) | Use your identity provider to sign in to 1Password. Your device stores its device key in platform-protected key storage. | If biometric unlock is turned on in your SSO settings, you can unlock with biometrics. An encrypted version of your 1Password data is stored locally, and your device stores the keys to unlock it in platform-protected key storage. |
| Other platforms (Windows, Linux) | Use your identity provider to sign in to 1Password. Your device stores your device key obfuscated on-disk. | If biometric unlock is turned on in your SSO settings, you can unlock with biometrics. An encrypted version of your 1Password data is stored locally, and your device stores the keys to unlock it in platform-protected key storage. If you quit 1Password and restart it, you must be connected to the internet to unlock again. |
| 1Password in the browser | Use your identity provider to sign in to 1Password. Your device stores your device key obfuscated on-disk. | Offline unlock is not available in the browser. |
In cases where someone gains access to a team member’s device or the data stored on it, Unlock with SSO used without biometrics is riskier than traditional unlock. In those scenarios, the combination of the device key and login information for the identity provider (gathered from cookie information in the web browser) could be used to gain access to a team member’s 1Password data. As a result, there’s a greater risk of passive attacks obtaining the information needed to access a team member’s account. These risks should be considered alongside other data exposure risks including how team members' data will be backed up and which threat actors are most likely to target team members.
When used with biometrics on supported devices, the risks when someone gains access to a device are comparable whether using Unlock with SSO or traditional unlock. In both cases, the ability to unlock 1Password is protected by the device’s biometric security.
If someone gained access to a team member’s SSO credentials, they could theoretically obtain a verification code used to link a new device through a phishing attack and gain access to a team member’s 1Password account. Team members should never share verification codes with anyone, and should only enroll devices in their possession.
Note that the risks described for Unlock with SSO are no greater than for other products that use SSO. In fact, to access a team member’s 1Password data, someone would need both the team member’s SSO credentials and their 1Password device key, a unique keyset used for decrypting account credentials, encrypting account credentials, and identifying the device to 1Password. With SSO credentials alone, someone would have access to all of the other services connected to the identity provider.
Unless biometrics are turned on by an administrator, team members who unlock 1Password with their identity provider lack offline access to their items. If the 1Password servers are down, if the identity provider’s servers are down, or if a team member can’t connect to the internet, team members won’t be able to access their items. This is a permission enforced by the 1Password apps. Read more about how permissions are enforced in 1Password accounts.
Technical design
Device keys
When an account is configured to unlock with an identity provider, a unique device key is generated by each device that signs in to the account. 1Password uses this key to decrypt and encrypt account credentials, identify the device, and help to link apps and browsers to your account. The device key remains on your device and is used to gain access to an account unlock key as described in the Security Design white paper.
If you choose to allow team members to unlock with biometrics, certain platforms can use device security features to protect the device key in the hardware itself.
Macs without Apple silicon or the T2 chip lack the hardware required for device key protection. On those devices, the device keys don’t have hardware protection. Learn more about the Secure Enclave.
To use 1Password on ChromeOS, you can use 1Password.com and the 1Password browser extension. Neither of these offer biometric or specific hardware protections for device keys. However, ChromeOS software and devices have been designed to mitigate certain risks related to the storage of device keys, which are worth consideration if you’re developing a strategy to adopt Unlock with SSO. Learn more about ChromeOS security.
Linked apps and browsers
When you set up unlock with SSO, the app or browser you use becomes your first linked app or browser. You can use this app or browser to verify your identity when you sign in to your account on other apps and browsers.
In a linked app or browser, you don’t need to enter a verification code each time you unlock 1Password, and you can also unlink apps or browsers from your account at anytime.
The 1Password server stores an additional encrypted version of your account unlock key for each registered device. To see a list of your linked apps and browsers:
- On 1Password.com, select your name in the top right and choose My Profile.
- In the 1Password apps, select icon your account or collection at top of the app, then choose Manage Accounts. Choose your account, then select Linked to Your Account.
Linking apps and browsers
Team members must use a linked app or browser to sign in to 1Password with an identity provider and authorize additional apps and browsers to sign in the same way.
When a team member links a new app or browser to their account, they’ll be asked to provide a randomly generated alphanumeric verification code from an existing linked app or browser to prove the additional app or browser can also be linked.
After they enter the verification code, 1Password securely transfers a credential bundle from their existing linked app or browser to the new app or browser. The new app or browser uses the bundle to sign in to their 1Password account, register itself as a linked app or browser, and encrypt the credential bundle with its own device key.
If successful, their new app or browser will be linked to their account. Otherwise, the process begins again when their existing linked app or browser generates a new verification code.
Why you have to link an app or browser to your account
The app or browser linking process is fundamental to 1Password’s end-to-end encryption. When you enter the verification code, 1Password securely transfers a credential bundle from your existing linked app or browser to the new app or browser. The new app or browser then uses the bundle to sign in to your 1Password account, register itself as a new linked app or browser, and encrypt the credential bundle with its own device key. This allows the new app or browser to sign in to your account and decrypt your 1Password data independently while keeping your secrets safe.
The app or browser linking process is not a form of multi-factor authentication, nor is it a replacement for existing device management programs your organization may have.
Learn more in Unlock with SSO: under the hood .
Unlinking an app or browser
When the 1Password app attempts to sign in and is notified that it’s deauthorized or the user is deleted, the app will delete the device key, effectively removing the linked app or browser.
Delegated sessions
Applications that have successfully completed an authentication flow can create new sessions on behalf of another client, allowing the second client to bypass the authentication flow. 1Password.com and the 1Password desktop apps can create sessions and delegate them to other applications, like the 1Password browser extension and 1Password CLI.
Delegated sessions don’t require re-authentication with the identity provider because they are extensions of an authenticated session that already exists. The session is delegated from the original application to the secondary application using a session key. This session key is a short-term secret.
Re-authentication tokens
Re-authentication tokens are long-lived tokens that can be used to re-authenticate with 1Password without requiring re-authentication with the identity provider. This token is protected by SRP.
The re-authentication token allows team members to unlock 1Password with biometrics instead of re-authenticating with their identity provider. 1Password administrators set the duration before re-authentication with the identity provider is required. This is an account-wide setting.
When a sign-in re-authentication token is used to re-authenticate with 1Password, it’s immediately revoked and a new re-authentication token is generated. This defends against accidental TLS confidentiality failures by quickly invalidating used sign-in re-authentication tokens. This doesn’t protect against well-executed man in the middle attacks where traffic is manipulated or observed when requests are in flight or in the brief moment when a used sign-in re-authentication token is still active.
Biometrics and offline access
Administrators can turn on biometrics alongside Unlock with SSO. This allows team members to access their items when offline. The time period for offline access is determined by the administrator of the 1Password Business account.
For team members who unlock 1Password with their identity provider without biometrics, there is no general support for offline access. If the 1Password servers are down, if the identity provider’s servers are down, or if a team member can’t connect to the internet, team members won’t be able to access their 1Password data. This is a permission enforced by the 1Password apps, most valuable as simple safeguards for people you already trust. Read more about how permissions are enforced in 1Password accounts.
The exception is if biometrics are turned on at the organization level, from the Unlock with SSO settings page. If turned on, offline access works when a team member unlocks their device with biometrics. The administrator determines the maximum allowed time period for offline access before a team member has to sign in with the identity provider. If their credentials are still cached from a prior session authenticated by the identity provider, team members will be able to unlock 1Password using biometrics. If a team member’s device doesn’t support biometrics, they won’t be able to access their items when offline, regardless of the organization-wide settings.