Skip to main content
InviziPoll
Sign inStart free trial

Single sign-on (SAML & OIDC)

Set up SAML 2.0 or OIDC single sign-on for InviziPoll admins on Business or Enterprise, what the owner must do first, and how keys unlock after SSO.

  • IT, identity admins
  • 5 min read
  • Updated Oct 14, 2026

Connect InviziPoll to your identity provider so admins sign in with the accounts they already have. SSO decides who can sign in; it doesn't unlock anyone's encryption keys, so a compromised IdP can't open your polls on its own; InviziPoll supports SAML 2.0 and OpenID Connect (OIDC); SSO is for admins signing in to your workspace; respondents never sign in, and SSO changes nothing about how their answers are protected.

The SSO and Provisioning tab. A Single Sign-On card explains that enterprise SSO over OIDC or SAML requires the owner to keep password sign-in and a recovery export, so the workspace stays recoverable without the identity provider. An Owner recovery prerequisites checklist shows password login satisfied and recovery export outstanding, followed by a Provider type selector set to OIDC and an Issuer URL field.
Admin, Team, SSO and Provisioning - identity provider setup and the owner recovery prerequisites.
Note

SSO lives under Admin → SSO & Provisioning (the shield icon in the sidebar, then the SSO & Provisioning tab). Only the workspace owner can see or change it.

#Which plans include SSO

SSO is included on Business and Enterprise. During a free trial, the owner can switch on the Business features preview from Subscription (the button reads Enable Business features for this trial) and try SSO, SCIM, verified domains and SIEM webhooks until the trial ends.

On other plans the SSO & Provisioning page still loads, but its controls are disabled with a notice to upgrade. Existing configuration can still be viewed and removed.

#Before you start

The owner has to be able to get back into the workspace without the identity provider, so two things must be true before the SSO Active switch unlocks. The card lists them under Owner recovery prerequisites:

  • Password sign-in on the owner's account. Email and password, not only a magic link or passkey. If it's missing, use the Set up in Account security link.
  • A recovery export on record. Download a recovery file from Settings → Backup & Recovery (or save the recovery kit offered during onboarding). The card links there as Back up your workspace.

You'll also want:

  • Admin access to your IdP (Okta, Microsoft Entra ID, Google Workspace, JumpCloud and similar).
  • A verified domain if you plan to limit sign-in to your company's addresses. See Domain verification (DNS TXT).
Note

Owners keep password sign-in as a break-glass route while SSO is active, even on a verified domain, and each use is recorded in the audit log. Everyone else on a verified domain must use SSO. Keep your recovery file and its password somewhere safe too. Sign-in policy and domain capture explains the rule.

#OIDC setup

  1. Register a client in your IdP. Create a web application with a client secret.
  2. Choose OIDC. In the Single Sign-On card, set Provider type to OIDC (OpenID Connect).
  3. Fill in the fields. Issuer URL, Domain Mapping, Client ID and Client Secret, then Save Configuration. The secret isn't shown again after saving.
  4. Add the callback. Once saved, the card shows Values for IdP (Okta / OIDC) with a Callback URI. Add it to your IdP app's sign-in redirect URIs.
  5. Test. With the prerequisites met and the client fields filled in, Test SSO Sign-In sends you through your IdP and back.

The callback URI has this shape:

text
https://<your InviziPoll address>/api/auth/sso/callback

Copy the exact value from the card rather than typing it.

#SAML 2.0 setup

  1. Create a SAML application in your IdP. Note its metadata URL, or download its metadata XML.
  2. Choose SAML. Set Provider type to SAML 2.0.
  3. Give us the IdP metadata. Paste the Metadata URL, or paste the XML into Or paste IdP metadata XML, then click Validate metadata. We read the entity ID, sign-in URL and signing certificate from it.
  4. Set Domain Mapping and save. Then Save Configuration.
  5. Give your IdP our metadata. After saving, a Service Provider (SP) Metadata section appears. Use Download SP metadata and upload that file to your IdP.

#Group claims and roles

If your IdP sends group IDs in the sign-in token (a groups or roles claim, or the Microsoft groups claim), InviziPoll matches them against the mappings on the Group-to-Role Mapping card. When nothing matches, the default role from your sign-in policy applies. Mappings live alongside SCIM; see SCIM directory sync.

#Turning SSO on

When the configuration is saved and both prerequisites show a tick, check SSO Active ("Allow workspace members to sign in with SSO"). Then set who may join through SSO in SSO sign-in policy and JIT provisioning.

To remove a connection, use Delete Configuration.

#After SSO: unlocking keys

SSO proves who someone is. Opening poll results also needs the encryption keys, and those are separate on purpose.

After an SSO sign-in, InviziPoll looks for keys in this order:

  • Keys already unlocked in this browser, or the encrypted copy this browser keeps.
  • A passkey with PRF support, if the admin has registered one.
  • Otherwise the admin goes to Approve this device, where they can verify their inbox with a code and then enter their password (or use their recovery kit), approve it from another of their own signed-in devices, or use a recovery file. Nobody else, owners included, can approve a device for them.
  • If none of that works, they can ask an owner. An owner can restore a colleague's access only after confirming a code with them directly; we can't do it for them.
Good to know

An attacker who controls your IdP can sign in as one of your admins, but that alone doesn't hand them the keys. They'd still need that admin's device, passkey, password or recovery kit. See Recovery, emergency kit, and device handoff.