Appearance
Enterprise SSO (SAML & OIDC)
Let your team sign in to Veriprompt with the identity provider they already use — Microsoft Entra ID, Okta, Google Workspace, Ping, or any standards-compliant IdP. Enterprise SSO covers single sign-on (OIDC and SAML 2.0), automatic role assignment from IdP groups, and SCIM 2.0 provisioning so joiners and leavers are handled by your directory instead of by hand.
Who this is for: company admins (ACCOUNT_OWNER / ACCOUNT_ADMIN). Everything below is configured on Settings → Single Sign-On (/settings/sso).
Availability: Enterprise SSO is a package feature. If you do not see the Single Sign-On entry in Settings, your plan does not include it yet — talk to your account manager. The gate is deliberately strict: SSO stays off until it is explicitly enabled on your package, even on premium tiers.
What you get
- One or two connectors per company — one OIDC and one SAML connector can be active at the same time (useful during a migration between IdPs).
- A stable login URL you can publish as an app tile:
https://app.veriprompt.tech/login/sso/<slug>. - Email-domain discovery — users type their work email on the normal sign-in page and get a Continue with … button, no URL to remember.
- Group → role mapping — an IdP group grants a Veriprompt role, re-checked at every sign-in.
- SCIM 2.0 provisioning — your IdP pushes creates, updates, and deactivations in real time.
- Optional SSO enforcement — require SSO for everyone in the company except account owners.
Step 1 — Create a connector
On Settings → Single Sign-On, click Add connector and choose the protocol.
Every connector starts in Draft — not usable for sign-in yet. Nothing you configure is live until you switch it to Active — users can sign in. You can move a connector back to Disabled — sign-in blocked at any time; disabling is instant and blocks every login path.
Pick a Login URL slug early — it is the stable part of your login URL and the redirect URI you hand to your IdP, so choose something durable like your company name.
OpenID Connect (OIDC)
| Field | What to enter |
|---|---|
| Display name | The button label your users see, e.g. Sign in with Contoso |
| Login URL slug | Short identifier, e.g. contoso |
| Issuer | The iss value your IdP puts in ID tokens — required |
| Authorization URL | Your IdP's OAuth authorize endpoint |
| Token URL | Your IdP's OAuth token endpoint |
| JWKS URI | Your IdP's signing-key endpoint |
| Client ID / Client secret | From the app registration you create in the IdP |
| Scopes | Defaults to openid profile email |
In your IdP's app registration, set the redirect URI to:
https://app.veriprompt.tech/api/auth/callback/<slug>The client secret is write-only. Once saved it is encrypted and never shown again — the UI only tells you whether a secret is set. To change it, paste a new one.
Microsoft Entra ID
Your values look like this (replace <tenant-id>):
Issuer: https://login.microsoftonline.com/<tenant-id>/v2.0
Authorization URL: https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
Token URL: https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token
JWKS URI: https://login.microsoftonline.com/<tenant-id>/discovery/v2.0/keysMicrosoft Graph groups fallback. Entra stops sending the groups claim when a user belongs to more groups than fit in a token. By default Veriprompt refuses such logins rather than treating "no claim" as "no groups". If your users hit this, tick Microsoft Graph groups fallback — Veriprompt then reads the full group list from Microsoft Graph. This requires the same app registration to hold the GroupMember.Read.All Application permission with admin consent. The option does not apply to SAML.
SAML 2.0
| Field | What to enter |
|---|---|
| IdP entry point (SSO URL) | Your IdP's sign-in URL (HTTP-Redirect binding) |
| IdP entity ID (issuer) | Your IdP's entity ID |
| IdP signing certificate (PEM) | The IdP's signing certificate — validation is pinned to exactly this certificate |
| Want assertions / response signed | Both default to on. Leave them on. |
Register Veriprompt in your IdP as a service provider with:
SP entity ID / audience: https://app.veriprompt.tech/api/auth/sso/saml/sp
ACS (reply) URL: https://app.veriprompt.tech/api/auth/sso/saml/<slug>/acsVeriprompt expects the user's email in an email attribute (the common OID and claim-URI variants are accepted too), and group values in the attribute named in Groups claim / attribute (default groups).
When you rotate the certificate at your IdP, paste the new PEM here before the old one expires — validation is pinned to the certificate on the connector, so an unannounced rotation stops logins.
Step 2 — Verify your email domains
Domain verification is what makes "type your email, get an SSO button" safe: only verified domains ever match, and a domain can belong to one company only.
On the connector, add the email domain (e.g.
contoso.com).Copy the DNS challenge shown in the UI and publish it as a TXT record at the domain apex:
contoso.com. TXT "vp-sso-verification=<your-token>"Click Verify.
If verification comes back unverified, the record has not propagated yet — that is not an error. Wait for your DNS TTL and click Verify again. The token stays visible until the domain verifies.
Verified domains do double duty: they drive discovery on the sign-in page, and they gate account creation. A user whose email domain is not verified for the connector cannot be provisioned through SSO.
Step 3 — Map IdP groups to roles
Under Group → role mappings, map each IdP group to the Veriprompt role its members should get.
- IdP group value — exactly what your IdP emits. For Entra this is the group's object GUID, not its display name. For Okta it is usually the group name. Add a readable label so the mapping stays reviewable a year from now.
- Role — you can map
USER,MEMBER,DEVELOPER,MANAGER, andACCOUNT_ADMIN.ACCOUNT_OWNERcan never be granted through SSO; owner changes stay a deliberate manual act. - Users without a mapped group — choose Deny sign-in (recommended) or Sign in with the basic User role. Denying is the default.
- Sync roles from IdP groups on every sign-in — when on, a user's role is refreshed at each login. If several mapped groups apply, the most privileged one wins.
Roles an admin set by hand inside Veriprompt are never overwritten by group sync. If you want the directory to own a user's role again, remove the manual override.
Step 4 — Turn the connector on
Switch the connector to Active — users can sign in, then test with a real account:
- Open
https://app.veriprompt.tech/login/sso/<slug>(or type a verified-domain email on the normal sign-in page and use the Continue with … button). - Complete the IdP prompt.
- Confirm you land in the right company with the expected role.
Keep a browser profile signed out, or use a private window, so you are testing the real first-login path.
Optional — Enforce SSO
Enforce SSO requires every member of the company to sign in through the IdP, disabling password sign-in for them.
Two guardrails are built in and cannot be turned off:
- Account owners and platform super admins are never subject to enforcement.
- Enforcement can only be enabled while at least one account owner still has a working password.
Together those guarantee a way back into your tenant if the IdP is ever unavailable.
Optional — SCIM 2.0 provisioning
Group sync only refreshes when someone signs in. SCIM lets your IdP push changes the moment they happen — which is what makes offboarding immediate.
Veriprompt implements the SCIM 2.0 Users resource: create, read, list (filter by userName or externalId), activate/deactivate, and delete (treated as a deactivation). Deactivating a user revokes all of their Veriprompt sessions right away and marks their company membership inactive, so the access review and compliance overview stop listing them as active members.
Reactivating in your IdP only undoes the IdP's own deactivation. If an admin also removed or deactivated the user in Veriprompt, they stay inactive until an admin reactivates them in Veriprompt.
Enable SCIM on the connector.
Click Generate token. The bearer token is shown once — copy it now. Veriprompt stores only a hash. Regenerating immediately invalidates the previous token.
Configure your IdP with:
SCIM base URL: https://app.veriprompt.tech/api/scim/v2/<connectorId> Bearer token: <the token you just copied>
Microsoft Entra ID: Enterprise application → Provisioning → mode Automatic → Tenant URL = the SCIM base URL, Secret Token = the bearer token → Test Connection → assign users and groups → Start provisioning.
Okta: app integration → Provisioning → SCIM connector base URL = the SCIM base URL, unique identifier = userName, authentication = HTTP Header / Bearer. Enable Create Users, Update User Attributes, and Deactivate Users.
Notes:
- SCIM enforces the same verified-domain and role rules as interactive sign-in. Users pushed for an unverified domain are rejected.
- The endpoint is rate-limited (120 requests/minute per connector), which is well above what Entra and Okta send during normal operation.
Multi-factor authentication with SSO
Veriprompt does not add a second factor to SSO logins. MFA for SSO users is your IdP's job — Conditional Access in Entra, sign-on policies in Okta. Veriprompt's own TOTP-based MFA continues to apply to password sign-in.
Enabling SSO without MFA at the IdP is a step backwards from password + Veriprompt TOTP. Turn on IdP-side MFA before you enforce SSO.
Troubleshooting
| What you see | What it usually means |
|---|---|
| No Continue with … button after typing an email | The domain is not verified, or the connector is not Active. Re-check both on Settings → Single Sign-On. |
/login/sso/<slug> says SSO is not available | The connector is Draft or Disabled, or the SSO entitlement is not on your package. Use the password link on that page. |
| Login fails right after the IdP prompt | Most often a redirect-URI / ACS URL mismatch, a wrong Issuer, or a rotated IdP certificate that was not pasted into the connector. |
| Users sign in but land with no access | Their group is not mapped, and Users without a mapped group is set to deny. Add the mapping or switch to the basic User role. |
| Entra users denied after joining many groups | Groups-claim overage. Enable Microsoft Graph groups fallback and grant GroupMember.Read.All. |
| SCIM test connection fails | Regenerate the token (it is shown once) and confirm the connector is Active — SCIM authentication requires it. |
Sign-in failures arrive back on the sign-in page with an sso_error code. Codes are intentionally vague about whose account was involved; your admins can see the specific reason in Audit Logs, filtered to sso.* and scim.* actions.
Emergency stop
If your IdP is compromised or a misconfiguration locks the company out, Veriprompt support can force-disable every connector for your company. New SSO logins stop immediately, existing SSO sessions end within about five minutes, and everyone falls back to password sign-in. Re-enabling is your own deliberate act on Settings → Single Sign-On once the IdP is fixed.