Audience: Organizations with Command Center
Single Sign-On (SSO) lets your users log in to Proof using your organization's existing credentials. Instead of managing separate Proof passwords, your identity provider (IDP) — like Okta, Microsoft Azure, or Google IdP — handles authentication. Once enabled, SSO applies to all users in your organization.
Benefits of SSO
- The most secure authentication method available for your users.
- Full control over user provisioning from your identity provider.
- Seamless onboarding and integration into your existing processes.
- Authentication requirements apply across all users with your domain.
Definitions
- Service provider (SP) = Proof
- Identity provider (IDP) = The entity you work with to create, maintain, and manage your identity information.
Requirements to Set Up SSO
You'll need all three of the following before getting started:
1
Your company must be a Proof Command Center customer. See the Command Center overview for more information.
2
You must have authority over a domain to verify with Proof.
3
You must have an identity provider (IDP), such as Okta, Microsoft Azure, or Google IDP. If you're unsure whether your organization has one, check with your IT or engineering contact.
What to Expect After SSO Is Enabled
Once SSO is turned on, all users in your organization must sign in to Proof through your IDP. Here's what changes:
| What Changes |
|---|
| Former Proof passwords will no longer work. Exception: Owners and admins with Command Center access can still use a password to log in. |
| Former Proof usernames will no longer work if they don't match existing usernames in your IDP. |
| Anyone with your email domain will not be able to create a new, separate Proof account. |
| Users with your email domain who already have a separate Proof account will lose access if they aren't provisioned in your IDP. |
⚠️
If any users in your organization have email domains you don't control, you can't enforce SSO for them. We recommend enabling MFA for those users instead.
⚠️
SSO applies to signers and recipients too. If your domain has SSO enabled, anyone with that domain — including signers or recipients of a transaction — must be provisioned in your IDP to access Proof. Users who are not provisioned on the IDP will be blocked from accessing the platform entirely.
If a signer or recipient is provisioned in the IDP but new to Proof, they will be just-in-time provisioned onto Proof when the transaction is sent and can SSO in immediately.
If a signer or recipient is provisioned in the IDP but new to Proof, they will be just-in-time provisioned onto Proof when the transaction is sent and can SSO in immediately.
⚠️
Exception: Carbon copy (CC) recipients are not prompted for SSO. CC recipients access the transaction through a PIN or access code sent to their email via the Verify Portal — there is no user login on the Verify Portal, so SSO is not triggered. This applies even if the CC recipient's email domain has SSO enabled.
Set Up SSO
Complete these steps in order:
1Verify your domain to confirm you have authority over it in Proof.
Summary Checklist
- Confirm your organization is a Command Center customer.
- Verify your domain with Proof.
- Set up SSO in your Proof account.
- Configure SAML settings with your identity provider.
- Ensure all signers and recipients with your domain are provisioned in your IDP before SSO is enabled.
Still Unsure?
Contact your Customer Success Manager (CSM) or submit a support request for help.
Updated