9 Unlock with a passkey or single sign-on
As an alternative to the sign-in method described in chapter “A deeper look at keys,” it’s also possible to sign in to 1Password with a passkey or single sign-on (SSO) provider.
Anyone can create an account that uses a passkey for authentication. When you set up an account this way, you provide your account’s passkey to unlock 1Password instead of an account password and Secret Key.
Companies that use 1Password can configure unlock with SSO for groups in their organization. When a user signs in with SSO, they sign in with the username, password, and other authentication factors required by their SSO provider instead of using their account password and Secret Key to authenticate to 1Password. 1Password accepts proof of authorization from the SSO provider as authentication.
9.1 Unlocking without an account password
We designed passkey and SSO unlock to work similarly to signing in with an account password and Secret Key in that both methods set up a process that uses Secure Remote Password (SRP) in a similar way. On devices where a user signs in with a passkey or SSO, 1Password clients store a device key. Each device key is uniquely and randomly generated, and never leaves the device on which it was created. To enroll a new device on a passkey or SSO-enabled account, the user must authenticate first then authorize the new device using a previously enrolled device.
A cryptographic key stored on a 1Password client that’s using single sign-on (SSO). It’s used to decrypt the credential bundle it receives from the server upon successful sign in.
With passkey and SSO unlock, your first device randomly generates an SRP-\(x\) and Account Unlock Key (AUK). They’re stored on our servers, encrypted by the device key that’s only stored on the device that created it. This combination of the SRP-𝑥 and AUK is called a credential bundle.
Consists of a randomly generated SRP-𝑥 and AUK, it’s used to sign in to 1Password with single sign-on (SSO). It’s encrypted by the device key and stored on 1Password servers.
Figure 9.1: Passkey sign in. The solid purple arrows illustrate the authorization of a device when a user performs a passkey sign-in, green arrows illustrate the return of the credential Bundle to the user, and dashed golden arrows illustrate the user’s authentication with SRP to use 1Password.
Figure 9.2: Single sign-on sign in. The solid purple arrows indicate a user signing in to their SSO provider. The solid red arrow shows the authorization the SSO provider sends to the 1Password server. The green arrows show the credential bundle being returned to the user. The dashed golden arrows show the user authenticating with SRP to use 1Password. This diagram is based on the OpenID Connect SSO authorization flow. For some SSO providers, the destinations of certain arrows may be slightly different.
9.1.1 Authorization and the credential bundle
Authorization to obtain the credential bundle happens as follows:
Passkey unlock The server authenticates your passkey and authorizes you.
SSO unlock During sign-in, the SSO provider tells 1Password servers you’ve successfully authorized. Typically, the SSO provider returns an authorization token to your device, which forwards it to the 1Password server.
In return for a valid proof of authorization, our servers return a credential bundle encrypted with the device key. After the 1Password client decrypts the SRP-\(x\) and AUK with the device key, it authenticates as described in “A deeper look at keys.” After successful sign-in with a passkey or an SSO provider, 1Password behaves identically to when an account password and Secret Key are used.
9.2 Linked apps and browsers
After you’ve successfully enrolled with a passkey or SSO, the app or browser you use is linked. The device you use stores a device key and sets up a unique credential bundle. The first client used to signed in to 1Password – either for the first time or after a user has been restored – is a linked app (or browser) by default.
A client trusted to use SSO, by having set up a device key and created a corresponding credential bundle.
The first app or browser you use to sign in creates a new set of randomly generated values that form the credential bundle. Any additional apps or browsers you enroll need approval. They’re approved by successfully authenticating to the SSO provider, consenting to the sign-in with an existing linked app, and providing a code that’s randomly generated by the linked device.
When you approve a sign-in within your linked app or browser, it sends a copy of the credential bundle to the new device via an end-to-end (E2E) encrypted channel. The new app protects the credential bundle with its own unique device key. The device key is critical for the overall security of SSO. Appendix A has more information about device key security and storage.
9.3 Linking other devices
When you set up a new app or browser, the credential bundle the device uses is obtained from a previously linked client. For your existing device to send the credential bundle to your new device, a trusted channel is set up between the two devices. For reliability, that channel is facilitated by 1Password servers and set up in such a way that 1Password can’t see what the two devices are sending each other.
The trusted channel between two devices uses the CPace cryptographic protocol. With CPace, two devices with knowledge of a six-character code can authenticate to one another and agree on a shared encryption key. That encryption key is used to encrypt the credential bundle when it’s sent from a linked device to a new device which makes the contents impossible to decrypt for anyone observing the encrypted messages. In the event a malicious server attempts to interfere in the key agreement process, 1Password clients detect the presence and abandon participation.
A modern PAKE using a shared secret, defined by Abdalla, Haase, and Hesse (CPace, a balanced composable PAKE.)17
With these building blocks, the process shown in Figure 9.3 and annotated below describes how a credential bundle safely travels between two devices.
Figure 9.3: An overview of the protocol by which a linked app or browser is added, showing the communication between the linked client, new device, and 1Password server. Any SSO providers that perform initial sign-in are not depicted.
Line 1: The parties involved are a new device, the server, and a linked app or browser. Your SSO provider, if applicable, also plays a small role initially but they’re omitted from the figure for simplicity.
Line 2: You sign in to 1Password with a passkey or SSO.
Line 3: The 1Password server sends a notification to all existing linked apps and browsers. They’ll notify you that a new device wants to be set up and you need to approve the connection on the existing device. If you choose to continue, you’ll have to sign in on the existing device unless you already have an active session.
Lines 4-7: Your existing device initiates a trusted channel with the new device using CPace. The existing device then generates a 6-character setup code, uses it to create a CPace handshake \(hs\), and sends the handshake to the 1Password server.
Lines 7-10: Your new device fetches the CPace handshake and asks you to enter your setup code. After you enter the setup code, your device computes a CPace reply \(r\) from information in both the CPace handshake and the setup code, then sends it to the 1Password server.
Both devices use the shared values to compute a shared session key \(k_s\).
Lines 11-13: Before the keys are used, it’s important to verify the keys have been exchanged correctly. After all, you may have accidentally entered the wrong setup code or there may have been something nefarious that tried to influence the messages sent between your devices.
To verify the keys, both devices compute an HMAC digest of the message they received from the other device using the key they both derived. They send these verification values to one another and verify whether the value computed by the other matches their own. If the values don’t match on either device they break off the setup process and start over again.
Lines 13-18: Your linked app or browser encrypts the credential bundle with (a derivative of) the session key established previously and sends them to your new device via the 1Password server. Your new device derives the decryption key the same way and decrypts the credential bundle. Next, the device generates a random device key, stores it, then encrypts the credential bundle with the device key. Your device stores the newly encrypted credential bundle on the 1Password server and completes the process to become a linked app or browser.
9.4 Quick on-device access with biometrics
The process described in Figure 9.2 requires that your device be online when unlocked. It’s possible for certain devices to get access to vault contents while offline if the user’s business account is configured to allow it. Offline access to vault contents is provided when a user successfully performs a biometric authentication. This is supported on Windows, Linux, macOS, iOS and Android using their respective platform’s biometric authentication.
When you unlock with biometrics, the credential bundle is used to decrypt vault contents locally so it can be accessed offline. Clients also keep track of a reauthentication token. This token is used to perform reauthentication with the 1Password server within a limited timeframe, without the client performing passkey unlock or reaching out to the SSO server. When an account administrator turns on biometric unlock, they temporarily delegate the responsibility of authenticating you to your device instead of your identity provider.
A reauthentication token is requested when you use biometrics to unlock your passkey or SSO-enabled 1Password account. It’s guarded by the protections described in “Transport security” when it’s transferred from the 1Password server to your device.
On macOS, iOS and Android devices, quick biometric unlock is protected by the respective platform’s built-in secure elements. On Windows and Linux, the reauthentication token is stored in protected operating system memory while the 1Password app is running either when locked or unlocked. On the platforms that store the reauthentication token in memory, the token is lost when the app closes or restarts, so you need to sign in to 1Password again.