SSO allows users to authenticate with their existing company credentials instead of a separate Tresorit password.
Authentication and encryption in Tresorit
Tresorit stores the encryption keys required to access a user's content in an encrypted container called the user profile.
When a user signs in on a new device:
- The client authenticates with Tresorit.
- The encrypted user profile is downloaded.
- The user profile is decrypted locally on the device.
- The encryption keys become available to access the user's content.
This allows users to access their data from multiple devices while maintaining Tresorit’s zero-knowledge architecture.
Standard password-based authentication
In password-based authentication, both authentication and user profile decryption are derived from the user's Tresorit password. The client generates separate cryptographic values:
- one for authentication
- one for decrypting the user profile
Because these values are derived using one-way cryptographic functions, the original password cannot be reconstructed. The password never leaves the device, and Tresorit never receives the keys required to decrypt user content.
SSO authentication
With SSO, authentication is delegated to an identity provider instead of a Tresorit password.
When a user signs in:
- The user authenticates on the identity provider’s login page.
- The identity provider verifies the credentials and returns a signed SAML assertion.
- Tresorit validates the assertion and grants access to the encrypted account.
- The client retrieves the information required to decrypt the user profile via the established trust with the identity provider.
Decryption continues to take place locally on the device. Tresorit does not receive passwords, plaintext encryption keys, or decrypted content. This shifts the trust model to the identity provider for authentication and access to account-related information during login.
Identity provider-specific considerations
| Azure AD | Uses a user profile extension attribute to store the information required for SSO-based access. |
| Google Workspace | Uses SAML-based authentication and does not store per-user application attributes for SSO access. |
| Okta | Stores the information required for SSO-based access as a user profile attribute. |
Infrastructure considerations
Tresorit's service infrastructure, including storage of encrypted user content, runs on Microsoft Azure. This may be relevant when evaluating Azure AD as an SSO provider.
Risk mitigation
Organizations handling highly sensitive information can further reduce risk by using the following controls.
Advanced Control
With Advanced Control, administrative actions still require the admin's Tresorit password, even when SSO is enabled.
Selective SSO deployment
SSO can be enabled only for specific groups via policy templates. This allows limiting SSO to selected users while keeping others on password-based authentication.