Best practices for using 1Password Unlock with SSO

When you first set up 1Password Business, your team members use a Secret Key and account password to sign in to their accounts. With 1Password Unlock with SSO, you can allow them to sign in with their identity provider credentials instead.

1Password Business supports two types of integrations with identity providers, and each has its own benefits:

To set up these integrations, you’ll need to create separate applications for each one in your identity provider. Separate applications are required because each of the integrations serves different functions.

In this article, you can learn more about how Unlock with SSO works and some best practices to follow when you set it up for your team. If you want to manage users from your identity provider, learn how to automate provisioning using SCIM.

Basics

When you unlock 1Password with an account password and Secret Key, these two encryption factors are combined to derive the two keys of the credential bundle (the Authentication Secret and Account Unlock Key) that allow you to sign in to 1Password and decrypt your data. We’ll call this Traditional Unlock.

By contrast, when you sign in to 1Password with SSO, you must first successfully authenticate with your identity provider. Then the 1Password servers will provide the encrypted credential bundle to your device. That credential bundle is decrypted on your device using the device key. The device key is a strong cryptographic key unique to each linked app or browser signed in to your 1Password account, and it never leaves your device.

In both unlock methods, the cryptographic keys that are necessary to access your 1Password data never leave your devices.

Sign-up flow

When you join a team account using Unlock with SSO, the app or browser you use becomes your first linked app or browser. This app or browser locally generates the two AES-256-GCM keys of the credential bundle directly and encrypts them with the device key, a third AES-256-GCM key. Linked apps and browsers each have a unique device key, which has encrypted your credential bundle and allows you to sign in.

The sign-up process takes place in a browser, which makes that browser the first linked browser. The device key is stored obfuscated in local browser storage, which is less at risk of being purged accidentally than the browser cache. However, if the local browser storage is cleared, the team member won’t be able to sign in.

Because the device key is unique to each linked app or browser, a critical part of migrating to Unlock with SSO is to make sure your team members link additional apps and browsers. Without access to at least one linked app or browser, they can’t sign in to new apps and browsers and will need an administrator to recover their account.

The app and browser linking process is fundamental to 1Password’s end-to-end encryption. It allows 1Password to securely transfer a credential bundle from your existing linked app or browser to a new app or browser using a symmetric Password Authenticated Key Exchange (PAKE) called CPace that offers Perfect Forward Secrecy.

Learn more about how to link apps and browsers to Unlock with SSO.

Authentication flow

When you sign in to 1Password with SSO, the following steps occur:

1. You open 1Password and choose to sign in or unlock the app.
2. 1Password initiates the SSO authentication process by checking for existing SSO authorization with the default browser.
3. If authorization is present, 1Password continues to the next step. If there isn’t authorization, you’ll be asked to sign in to your identity provider.
4. After authorization is given, the 1Password servers confirm it and provide the 1Password app with the encrypted credential bundle.
5. The 1Password app decrypts the credential bundle using its device key.
6. The 1Password app decrypts locally cached data using the Account Unlock Key, then initiates authentication with the 1Password servers using the authentication secret through the SRP protocol.
7. 1Password is unlocked and ready to use.

With OIDC and Proof Key for Code Exchange (PKCE), 1Password makes sure that the access token can be redeemed only by the client that requested it. The 1Password servers then wait for a yes or no response from the SSO provider and no other authentication is necessary. This means that you control which conditional access policies a team member has to meet to receive authorization.

Migration flow

If your team is already using 1Password and you switch to Unlock with SSO, each team member scoped for Unlock with SSO will go through a cryptographic key exchange. This will replace the credential bundle that’s based on their Secret Key and account password with a bundle generated by the 1Password app and encrypted with the device key on their first linked app or browser.

After they migrate to Unlock with SSO, all other devices they have previously signed in to their 1Password account will need to be set up as linked apps or browsers by authenticating with SSO. They’ll get a code from their first linked app or browser, use that to approve the new one, and so on.

Risk considerations

Unlock with SSO and 1Password’s standard unlock model have different security properties for end-user devices that you should consider. Neither option is inherently more secure than the other, but each has different benefits. Learn about 1Password Unlock with SSO security and refer to pages 42-48 of the 1Password Security White Paper for a more in-depth description.

Planning your rollout

When you introduce Unlock with SSO to your team, prepare some communication strategies to let them know about the upcoming changes. You should also roll it out in stages to make sure users are informed and your IT team is ready to handle potential support requests. Before you start, learn about some of the other things to keep in mind below.

Owner accounts won’t Unlock with SSO

In a 1Password Business account, people in the Owners group will always use Traditional Unlock. Owner accounts cannot be scoped for Unlock with SSO because if they lost access, vaults and items in the account may also be lost if there’s no one to recover them. This is also helpful in the case of an identity provider outage that prevents signing in with SSO. Owners are able to sign in to 1Password and un-scope specific groups or the entire team from Unlock with SSO, which switches them back to Traditional Unlock so they can access 1Password.

Similarly, when you integrate 1Password with your identity provider for automated provisioning SCIM, the 1Password servers provide a safeguard to prevent a malicious identity provider administrator or a malfunctioning 1Password SCIM bridge from locking your organization out of your 1Password tenant entirely: The last remaining owner account cannot be de-provisioned through SCIM.

Owner accounts can be considered super-admins in a 1Password account and serve break-glass purposes in the context of Unlock with SSO and automated provisioning. They need to be set up and protected properly.

Interactions between SCIM and SSO

When you turn on Unlock with SSO, you’ll be able to choose who can sign in and Unlock with SSO. The policy that you choose will determine how new users sign in, such as:

• Everyone or Everyone except: guests: All users in the Team Members group (the default group for new users) will Unlock with SSO.
• Only groups you select: Automated provisioning is required to scope new users for SSO before they sign up. Each identity provider handles group management differently, so keep this in mind when planning your deployment. Changes to group membership also cannot happen at the same time as the user’s account is activated.

If users aren’t part of a group that unlocks with SSO, they’ll use a Secret Key and account password to sign in. To allow them to Unlock with SSO, move them to one of the selected groups for SSO or add their group to the selected groups. Then they’ll set up their first linked app or browser the next time they sign in.

When you use Unlock with SSO alongside automated user provisioning, make sure attribute mappings are consistent between your provisioning application and your SSO application in your identity provider. For example, if you’ve configured your identity provider to send a certain attribute for user email addresses in 1Password, make sure your OIDC application is successfully sending that attribute as an OIDC claim. You can learn more about attribute mapping in the setup documentation for your identity provider.

Staging your rollout

As you plan the deployment of Unlock with SSO to your team, consider one or two groups who can test the new unlock method before you roll it out to your entire organization. This can be your IT department, developers, and other users who are more technical. You can even create a custom group for this project.

When you first set up the integration, test it yourself and make sure your IT support team understands the changes you’ll be making to the account so they can help when needed. Then expand Unlock with SSO to an entire group for further testing.

Gather feedback from their experiences during a one to two week period. If things are going well, grant other groups access, and continue until all the groups have successfully migrated. As you go, you may need to adjust special settings, such as Conditional Access policies in Microsoft Entra ID, which may only allow users to sign in from various environments or locations.

If you have hundreds or thousands of users, roll out Unlock with SSO slowly to make sure that your IT support team can keep up with any questions or issues that come up along the way. Your employees will be used to unlocking 1Password with their account password, so this new habit will take a little bit of adjustment, and some questions will arise. A nice upside is they now have one less password to remember.

Learn more

• Unlock with SSO: under the hood
• About 1Password Unlock with SSO security