Single Sign-On (SSO)
Enterprise customers can sign in to VerifyHuman using their corporate identity provider via SAML 2.0 or OpenID Connect. SSO is available on the Pro and Enterprise plans.
Supported providers
VerifyHuman SSO works with any SAML 2.0 or OIDC identity provider, including the major enterprise IdPs. If your IdP supports SAML 2.0 or OIDC, it will work.
How SSO works
End user VerifyHuman Your IdP
│ │ │
│ 1. Visit /auth/login │ │
│───────────────────────────────►│ │
│ │ │
│ 2. Redirect to your IdP │ │
│◄───────────────────────────────│ │
│ │ │
│ 3. Authenticate at IdP │
│────────────────────────────────────────────────────────────────►│
│ │
│ 4. IdP returns assertion to VerifyHuman │
│ │◄───────────────────────────────│
│ │ │
│ 5. VerifyHuman matches the assertion to your organization, │
│ enforces your domain allowlist, provisions the user (JIT) │
│ if first-time, and signs them in. │
│◄───────────────────────────────│ │
A user's first SSO login automatically provisions a VerifyHuman account, attaches it to your organization, and assigns the default member role you configure.
Provisioning your connection
SSO connections are configured by the VerifyHuman team in coordination with your IdP administrator. The flow is:
- Open a request from Settings → Security → Single Sign-On in the dashboard, or by emailing enterprise@verifyhuman.io.
- Share your IdP details with our enterprise team. We support SAML 2.0 and OIDC; the specific artifacts (metadata XML, ACS URL, entity ID, OIDC client) depend on your IdP.
- VerifyHuman creates the connection and attaches it to your organization. You will receive a test login URL.
- Test the connection with a pilot user. Once it's working, configure the per-organization settings below.
The owner-controlled, dashboard-managed settings are:
| Field | Description |
|---|---|
| Allowed email domains | Comma-separated list (e.g. acme.com, acme.co.uk). Only users whose IdP-asserted email is in this list can sign in via SSO. Required. |
| Default member role | Role assigned to new SSO users on first login (any role from the RBAC catalog; typically read_only or developer). |
| Enforce SSO | Once your pilot is successful, flip this on to require all members of your org to sign in via SSO (no password fallback). |
Domain enforcement
The Allowed email domains list is enforced at the SSO callback. Users whose IdP-asserted email is outside the allowlist are rejected before any account is created or modified. This prevents an IdP misconfiguration from accidentally creating accounts for non-employees.
Enforcement modes
| Mode | Behavior |
|---|---|
| Optional SSO (default) | Members can sign in via SSO or password. Use during pilot. |
| Enforce SSO | Members must sign in via SSO. Password login for org users is blocked. |
Enforcement is configured per-organization. Other VerifyHuman accounts are unaffected.
Just-in-Time (JIT) provisioning
When an authenticated SSO user signs in for the first time, VerifyHuman:
- Creates a VerifyHuman user record from the IdP assertion (email, first name, last name).
- Attaches the user to your organization as a member.
- Assigns the default member role you configured.
- Logs the event in your audit log.
You do not need to pre-create users. You can revoke access by removing the user from your IdP — the next login attempt will fail.
SCIM provisioning
SCIM-based provisioning is on the roadmap. Today, JIT covers create-on-login; deactivation flows through your IdP.
Audit events
The following events are written to your organization's audit log and are also available via webhook:
| Event | When |
|---|---|
org.member.login.via_sso |
A member successfully signed in via SSO |
org.member.created.via_sso |
A new member was JIT-provisioned via SSO |
org.sso.settings.changed |
An owner updated SSO configuration |
You can stream these to your SIEM via the Webhooks API.
Troubleshooting
| Symptom | Likely cause | Resolution |
|---|---|---|
Email domain not allowed |
The IdP-asserted email's domain is not in your allowlist | Add the domain to Allowed email domains in SSO settings |
Unknown organization after IdP login |
The IdP organization ID is not yet linked on VerifyHuman's side | Contact enterprise support — we need to attach the connection to your org |
| Stuck redirect loop | IdP entity ID / ACS URL mismatch | Reach out to enterprise support; we'll re-import the connection metadata |
SSO required on password login |
Enforcement is on but the user is trying to use the password form | Direct the user to your IdP login portal, or temporarily disable enforcement |
| New SSO user has no permissions | Default member role is too restrictive | Update Default member role in SSO settings (existing users keep their assigned role) |
Frequently asked questions
Can I require SSO for some users but not others? Enforcement is per-organization. You can keep one organization optional (e.g. an internal sandbox) and another enforced.
Do API keys still work when SSO is enforced? Yes. API keys authenticate machines, not humans. Enforcement affects browser sign-in only.
What happens if my IdP is down? Enterprise customers can request a temporary break-glass admin email be added by VerifyHuman support. This bypass is logged and time-limited.
Can I see who signed in via SSO?
Yes — every successful SSO login writes org.member.login.via_sso to your audit log with timestamp, IP, and user.