Skip to Content
AdministrationSingle sign-on

Single sign-on

Connect Microsoft Entra ID or Okta so members can sign in with their organization account. VeriProof supports one verified connection for the organization. The provider controls who can start sign-in; VeriProof controls membership and access after sign-in.

Before you start

You need:

  • VeriProof administrator access.
  • Permission to create a web application in Microsoft Entra ID or Okta.
  • A second Administrator who already has an active VeriProof account.
  • A separate administrator session that you can keep open while you test.
  • The corporate email domains that should direct members to this connection.

Do not use your only VeriProof Administrator for the first sign-in test. Use a second Administrator and keep the original administrator session open.

Connect your provider

Start setup

Open Settings → SSO configuration, then select Set up single sign-on. Choose Microsoft Entra ID or Okta.

For Microsoft Entra ID, enter the discovery endpoint for your tenant. VeriProof does not accept shared endpoints such as common, organizations, or consumers.

For Okta, enter your Okta organization domain without https://, such as example.okta.com.

Create a web application

Create an OpenID Connect web application in your provider and enable the Authorization Code flow. Assign only the people or groups who should be able to open VeriProof.

Copy the redirect URI shown by VeriProof and add that exact value to the provider application. Each VeriProof environment has its own redirect URI.

Add the credentials

Copy the application’s client ID and client secret into VeriProof. VeriProof encrypts the secret and does not show it again.

Store the secret’s owner and expiration date in your organization’s secrets manager. Never add a client secret to a ticket, chat, or source file.

Run the configuration checks

Select Run configuration checks. VeriProof checks the provider configuration, sign-in addresses, signing keys, and the required openid, profile, and email permissions. Your client ID, client secret, returned identity, and redirect are verified during Verify sign-in.

Resolve every failed check before you save.

Save the connection

Save the configuration. Its status remains Sign-in test required until a member completes the next step.

Verify sign-in

Keep your original administrator signed in through another browser profile or private window. In the setup browser, select Verify sign-in. VeriProof leaves Settings, asks the provider to authenticate the second Administrator, then returns to Settings as that Administrator. The email must match one active VeriProof member in the same organization.

VeriProof marks the connection Active only after the sign-in response, identity, organization, and membership checks succeed. Returning to Settings does not by itself prove success. Confirm the success message and Active status in either administrator session.

Register the email domain

Ask the onboarding owner to register each corporate email domain. Include the organization name, provider, environment, and domains. Members cannot discover the connection from the email-first sign-in page until registration is complete.

How members sign in

  1. The member enters their work email on the VeriProof sign-in page.
  2. VeriProof matches the email domain to an active, verified organization connection.
  3. The page shows only that organization’s sign-in button.
  4. The identity provider authenticates the member. VeriProof requests fresh authentication; the provider’s policy decides whether that requires a password, an authenticator, or another challenge.
  5. VeriProof confirms that the provider identity belongs to an active member and applies the role stored in VeriProof.

Provider groups determine who can open the provider application. VeriProof membership and roles determine what the member can access in VeriProof.

Single sign-on by itself only signs members in. VeriProof does not create members or assign roles from provider groups. An administrator must add each member in Settings → Team → Members and assign the VeriProof role before the first sign-in, unless identity provisioning adds people through SCIM and grants roles from mapped groups.

If verification does not succeed

  • The member returns to Settings, but the connection is not Active: review the message on the SSO page, correct the provider configuration, and run Verify sign-in again.
  • The email-first sign-in page cannot find the connection: confirm that the connection is Active and that the email domain has been registered.
  • The provider signs in, but VeriProof denies access: confirm that the email returned by the provider is verified and exactly matches an active member in this organization.
  • The wrong person is selected at the provider: sign out of the provider or use a separate browser profile, then start Verify sign-in again.

What happens when a member signs out

Signing out clears the member’s VeriProof session. It does not sign the member out of Microsoft Entra ID, Okta, or other applications that use the same provider session.

VeriProof still requires the provider to authenticate the member again on the next VeriProof sign-in. An existing provider browser session cannot silently restore the VeriProof session.

For a shared or public computer, members should also sign out of the provider and close the browser.

Maintain the connection

  • Rotate the client secret before it expires and after any suspected exposure.
  • After updating the client secret in VeriProof, run the configuration checks and Verify sign-in again.
  • Keep at least one tested administrator recovery path outside the member account used for verification.
  • Disable the connection before planned provider changes that could interrupt sign-in.
  • Delete the configuration when the organization no longer uses that provider.

Release checks

Before making the connection available to members, confirm that:

  • The configuration shows Active.
  • The organization’s email domain opens the correct provider sign-in.
  • An assigned member reaches the correct VeriProof organization and role.
  • An unassigned provider user is denied.
  • A provider user without an active VeriProof membership is denied.
  • Signing out of VeriProof prevents silent sign-in with a remaining provider session.
  • Secret rotation succeeds and the updated connection passes Verify sign-in.

Provider references

Provider notes

Microsoft Entra ID

  • Use a single-tenant web application and a tenant-specific v2.0 discovery endpoint.
  • Copy the client secret value into VeriProof, not the secret’s identifier.
  • Add the exact redirect URI shown for the current VeriProof environment.
  • Assign the test member to the application when assignment is required.

Okta

  • Create an OpenID Connect web application with the Authorization Code grant.
  • Add the exact redirect URI shown for the current VeriProof environment.
  • Assign the test member or test group to the application.
  • Confirm that Okta returns the member’s email and marks it as verified. VeriProof rejects an identity whose email is missing or unverified.
Last updated on