Single Sign-On (SSO)

Single Sign-On lets your team sign in to Hindsight Cloud with your existing identity provider (IdP) — such as Okta, Microsoft Entra ID (Azure AD), or Google Workspace — instead of a separate Hindsight password. Once SSO is configured, anyone with an email address on your verified domain is routed to your IdP automatically.

Enterprise feature

SSO is available on Enterprise plans. If you don't see the Single sign-on section on your Team page, book a call or contact your Hindsight representative to enable it for your organization.

Overview

SSO is managed on the Team page (organization owners only), because it replaces email invites — members are provisioned automatically on first sign-in. Setup is a short wizard:

1. Choose your identity provider.
2. Connect it — copy Hindsight's service-provider (SP) values into your IdP, and enter your IdP's details.
3. Verify your email domain — prove you own the domain. SSO then turns Active on its own.

Step 1 — Choose your identity provider

1. Go to Team and turn on the Single sign-on toggle to open the setup wizard.
2. Choose your identity provider — Google Workspace, Microsoft Entra ID, Okta, or a generic OIDC / SAML provider. Picking one pre-fills the settings and lists the exact steps to follow in your IdP.

Step 2 — Connect your identity provider

The Connect step shows the service-provider (SP) values your IdP needs so it trusts Hindsight — each has a copy button. Configure your IdP with them, then save.

For OIDC (Google, Entra, Okta, or generic OIDC):

1. Copy the Redirect URI shown at the top of the step (e.g. https://auth.hindsight.vectorize.io/idps/callback). It's available before you save, so you can set up your IdP first.
2. In your IdP, create an OIDC / OAuth web application and add that Redirect URI as an allowed sign-in redirect / callback URL.
3. Back in Hindsight, enter the Issuer URL (pre-filled for Google), Client ID, and Client Secret, then click Save identity provider.

Microsoft Entra ID

Entra works with no extra token configuration — Hindsight reads the name from Entra's name claim and the address from preferred_username. Two settings are still worth making, for one specific reason each.

Add the email optional claim — recommended. Without it we fall back to preferred_username, which is the user's UPN. In many tenants the UPN lives on <tenant>.onmicrosoft.com while real mail is @yourcompany.com. Sign-in still succeeds, but users are matched on the UPN, so they won't match your verified domain and won't be placed in your organization. If your UPNs and email addresses are identical, this doesn't affect you.

Add given_name and family_name — optional. Without them we split the display name on the first space, which is right for "Ada Lovelace" but guesses for compound surnames ("Ada van der Berg" → "Ada" / "van der Berg", correct; "Ada King Lovelace" → "Ada" / "King Lovelace", middle name absorbed). Adding the claims makes names exact.

Both live under App registration → Token configuration → Add optional claim → ID. Entra will then prompt you to add the matching API permissions → Microsoft Graph → Delegated: openid, profile, email — the claims are only issued once those scopes are declared. Grant admin consent afterwards if your tenant restricts user consent, as most do.

Issuer format. Use the tenant-GUID form:

https://login.microsoftonline.com/<directory-tenant-id>/v2.0

The <tenant>.onmicrosoft.com form also works but normalizes to the GUID. The common endpoint does not work — it returns a placeholder issuer that fails validation. Register the app as single tenant.

For SAML:

1. Describe your IdP, using whichever of the two your provider supports:

   • Metadata URL — paste the URL your IdP publishes its SAML metadata at.
   • Enter values manually — turn this on and paste three values instead: SSO URL, Entity ID, and the X.509 certificate. Use this when your IdP has no metadata URL to give you.

   Then click Save identity provider.

2. Hindsight then generates your SP values (they require the saved IdP). Copy them into your IdP's SAML application:

   • ACS URL (Assertion Consumer Service / "Single sign-on URL")
   • Entity ID (SP entity / "Audience URI")
   • Or paste the SP metadata URL if your IdP can import SP metadata instead.

Google Workspace publishes no metadata URL

Google's SAML setup offers a metadata file to download, or the same three values to copy — but no URL to fetch them from. Use Enter values manually and copy Google's SSO URL, Entity ID, and Certificate straight across.

The certificate can be pasted either way — with the -----BEGIN CERTIFICATE----- lines or just the block of base64 inside them.

Two SAML settings in your IdP matter and are easy to miss:

• NameID format — set it to EMAIL. Google and some others default to UNSPECIFIED, which prevents Hindsight from matching the user to their account.
• Attribute mapping — map the user's email, first name, and last name. Hindsight links accounts by verified email, so the email attribute is the one that must be right.

tip

Copy each value exactly — a trailing slash or a wrong scheme (http vs https) will cause the login to fail.

Step 3 — Verify your email domain and enable SSO

Hindsight routes users to your IdP based on their email domain, so you must prove you own the domain first.

1. In the Email domains section, enter your domain (e.g. acme.com) and click Add domain.

2. Hindsight shows a DNS TXT record to publish. It looks like:

   Name:  _hindsight-sso.acme.com
   Type:  TXT
   Value: hindsight-sso-verify=<token>

3. Add that TXT record in your DNS provider. Propagation can take a few minutes.

4. Back in Hindsight, click Verify. When the record is found, the domain flips to Verified.

5. With the Single sign-on toggle on and at least one domain verified, SSO turns Active automatically — no separate "enable" step. (Until then the toggle stays on but shows what's left to finish.)

note

Public email domains (like gmail.com or outlook.com) can't be used for SSO, and a domain can only be verified by one organization.

How your team signs in

Once SSO is Active:

1. A user goes to the Hindsight Sign in page and enters their work email.
2. Hindsight recognizes the domain and shows Continue with <Your Org> SSO.
3. They authenticate with your IdP (including your IdP's own MFA, if any).
4. They're returned to Hindsight, signed in.

On a user's first SSO sign-in:

• If they already had a Hindsight account with that email, it is automatically linked — their history is preserved.
• They're added to your organization as a member. Owners can promote roles afterward on Team Members.

Users don't need to do anything to set up — they just enter their work email.

Managing SSO

• Edit the IdP configuration any time on the Team page (owners only). Leave the client secret blank when editing to keep the current one.
• Turn off the Single sign-on toggle to stop routing users to your IdP (existing users keep their Hindsight accounts).
• Remove a domain to stop routing that domain.
• Disconnect the configuration to remove the identity provider entirely. To switch between OIDC and SAML, disconnect first, then set up the new provider — your verified domains are kept.

Multi-factor authentication (MFA)

With SSO active, MFA is your identity provider's job. Your IdP performs the authentication, so whatever it requires — including MFA — applies to Hindsight sign-ins.

Hindsight's own MFA enforcement setting and SSO cannot both be on for the same organization. Turning on either while the other is active is refused, in both directions:

• Enabling MFA enforcement while SSO is active → "Cannot enable MFA enforcement while SSO is active for this organization."
• Activating SSO while MFA enforcement is on → "Cannot activate SSO while MFA enforcement is on for this organization."

To switch, turn the first one off before turning the second one on.

This is deliberate. Hindsight cannot tell from a sign-in whether your IdP performed a second factor — most providers don't pass that signal through — so enforcing Hindsight MFA on top of SSO would prompt every SSO user for a second factor that your IdP doesn't own, can't audit, and can't revoke when someone leaves. Requiring MFA at your IdP covers your whole organization properly, including Hindsight.

Troubleshooting

Problem	What to check
"Continue with SSO" doesn't appear	The domain isn't verified, or SSO isn't Active. Confirm both on the Team page.
Login fails after the IdP redirect	The Redirect URI (OIDC) or ACS URL / Entity ID (SAML) in your IdP must match the values shown in Hindsight exactly.
Users sign in but land in the wrong organization (or none)	The address your IdP asserts isn't on a verified domain. On Entra this usually means the UPN differs from the mail address — add the email optional claim. See the Entra note in Step 2.
"Domain already verified by another organization"	The domain is verified elsewhere. Contact support.
Users land on the password screen instead	They may be typing a non-verified domain (e.g. a personal email). SSO only applies to verified domains.
"Cannot activate SSO while MFA enforcement is on"	The two are mutually exclusive — turn off MFA enforcement in your organization's security settings first. See MFA.
SAML login succeeds at the IdP but Hindsight doesn't recognize the user	Check the NameID format is EMAIL (not UNSPECIFIED) and that the email attribute is mapped.
No Metadata URL to enter for SAML	Your IdP may not publish one. Turn on Enter values manually and paste the SSO URL, Entity ID, and certificate.

Need help? Contact your Hindsight representative or support.