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
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 trusted device verification code through a phishing attack and gain access to a team member’s 1Password account. Team members should never share trusted device 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, each 1Password client generates a unique key. This key is used for decrypting account credentials, encrypting account credentials, and identifying the device to 1Password. The device key is also used in the process of enrolling additional devices. The device key is never used to encrypt or decrypt other keysets, groups, or vault data in 1Password.
When enabled, on certain platforms Unlock with SSO can use the biometric security features of a device to protect the device key in hardware.
| 1Password platform | Biometric device key protection |
|---|---|
| macOS | Yes, on devices with Apple silicon or a T2 chip |
| iOS | Yes, using TouchID and FaceID |
| Windows | No |
| Android | Yes, using biometric unlock |
| Linux | No |
| 1Password browser extension | No |
| 1Password.com | No |
Note that macOS devices without an Apple silicon or T2 chip lack the hardware required for device key protection. On those devices, the device keys do not have hardware protection.
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 in safe storage of device keys which are worth considering if you are developing a strategy adopting Unlock with SSO.
Trusted Devices
A Trusted Device is one that you’ve signed in to and that 1Password knows is yours. You can use a Trusted Device to verify your identity on another device or browser.
On a Trusted Device, you don’t need to enter a verification code each time you unlock 1Password. You can follow the Trusted Device enrollment steps to grant a new device trusted status. The 1Password server stores an additional encrypted version of an account’s unlock key for each device registered to the account. You can see a list of Trusted Devices on your My Profile page.
Trusted Device enrollment
Trusted Devices are required for team members to sign in with an identity provider. When a team member enrolls a new device, they prove their identity by signing in to their identity provider.
Team members must use an existing trusted device to authorize additional devices. When a team member attempts to sign in to 1Password with a new device, they must retrieve a randomly generated alpha-numeric verification code from one of their existing trusted devices and enter it on the new device to prove that the new device can be trusted.
If successful, the new device becomes a trusted device. Otherwise, a new verification code is generated and the process begins again.
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.