Configure SSO and SCIM

This page explains what Wistia's SSO and SCIM provisioning actually support and how to wire them up to your identity provider. It's for IT admins and developers integrating Wistia with Okta, Microsoft Entra ID, or another IdP. For click-by-click setup screens, see the Help Center; this page is the capability and protocol reference.

Single Sign-On (SSO)

Wistia supports SAML 2.0 SSO via any SAML 2.0 identity provider, including Okta, Microsoft Entra ID, OneLogin, and others. There is no IdP-specific integration: you configure SSO by giving Wistia your IdP's metadata URL, and Wistia handles the rest.

Key facts to plan around:

SP-initiated only. Users start sign-in from Wistia. IdP-initiated sign-in — launching Wistia from an Okta or Entra dashboard tile — is not supported.
SAML 2.0 only. OIDC is not supported for customer SSO.
Automatic attribute mapping. Wistia maps the standard SAML attributes for email, first name, and last name. No custom attribute mapping is required.
Configured by an owner or admin in Account settings → SSO setup. SSO is available on higher-tier and Enterprise plans; contact your account team if you don't see it.

Enabling vs. requiring SSO

SSO has two states, and the difference matters for your rollout:

Enabled — SSO becomes an available way to log in. An SSO option appears and SP-initiated sign-in works, but password login still works too.
Required — all users must log in with SSO. The account owner and Wistia admins keep a password fallback so you can't lock yourself out, but everyone else is forced through your IdP.

📘
Account SSO does not gate Channel viewers. Requiring SSO controls who can log into your Wistia account (your team). It does not restrict who can watch a public Channel, and there is no per-Channel SSO setting. To restrict Channel viewing, use password protection, a private Channel, or Channel roles — see your Help Center for those settings.

Rotating certificates, changing your metadata URL, and migrating IdPs

Because Wistia stores your IdP's metadata URL rather than a static copy of your SAML certificate, most certificate and IdP lifecycle changes are self-serve — and some require nothing at all on the Wistia side. This section covers what happens when your signing certificate rotates, when you need to change the metadata URL itself, and when you migrate to a different SAML provider.

How Wistia consumes your metadata

Wistia stores the metadata URL you enter in Account settings → SSO setup — a live URL that points at your IdP's SAML metadata document, not an uploaded certificate blob. Your signing certificate, entity ID, and SSO endpoints all live in that document. The practical consequence: the source of truth is your IdP, and Wistia reads from the URL you gave it.

Certificate rotation

If your IdP rotates its SAML signing certificate and your metadata URL stays the same, there is nothing to do in Wistia — the new certificate is published at the same metadata URL, and sign-ins continue to work. A certificate that is expiring does not, on its own, require you to re-enter or change the metadata URL.

Coordinate a rotation with your IdP admin so the new certificate is live before the old one expires. If your IdP requires you to replace the metadata URL as part of the rotation (some do), follow "Changing your metadata URL" below.

Changing your metadata URL

To point Wistia at a new metadata URL — a new cert that changed the URL, a tenant move, or a provider migration:

In Account settings → SSO setup, enter the new Metadata URL in the same field you used originally and submit.
Wistia updates your existing SAML provider in place — the same connection is repointed, so enrolled users don't need to be re-provisioned.
Confirm the change with an SP-initiated test sign-in (start from Wistia — IdP-initiated sign-in is not supported).

📘
Updates are transactional. If Wistia can't configure the new metadata URL, the change is rolled back and your previous working metadata URL stays in effect — a failed update won't lock users out. Fix the error and resubmit.

Migrating from one SAML provider to another

Moving SSO from, say, Microsoft Entra ID to JumpCloud (or Okta to Entra) is a metadata URL change, not a rebuild:

Stand up the new SAML app in your target IdP and get its metadata URL.
Enter that URL in SSO setup and submit — Wistia repoints the existing connection.
Run an SP-initiated test sign-in before you decommission the old IdP app.

Because Wistia maps the standard SAML attributes automatically (email, firstName, lastName), no attribute remapping is required as long as the new IdP emits those. Keep the old IdP app active until the test sign-in succeeds so you can revert by resubmitting the old metadata URL.

🚧
If SSO is set to Required, keep the account owner's and Wistia admins' password fallback available during a migration. Everyone else is forced through your IdP, so a broken metadata URL blocks their sign-in until it's fixed.

Common failure modes

Metadata URL error on submit. Wistia validates that the field is a well-formed URL before submitting; a submission that reaches Wistia but fails returns the error inline and leaves your previous configuration in place. Confirm the URL is publicly reachable, returns valid SAML metadata, and isn't behind auth or an IP allowlist that blocks Wistia.
Sign-ins fail after a cert change but the URL didn't change. The new certificate likely isn't published at the metadata URL yet, or the IdP is still serving the old one. Verify with your IdP that the current metadata document reflects the active certificate.
Users can't start sign-in from the IdP dashboard. Expected — Wistia is SP-initiated only. Users must start from Wistia; IdP-initiated tiles won't work.

For point-and-click screens to enter or update the metadata URL, see the Help Center. This page covers the protocol and lifecycle mechanics; the Help Center covers the setup UI.

User provisioning with SCIM

Wistia supports SCIM 2.0 for automatic user and group provisioning and deprovisioning from your IdP. Like SSO, it's generic — any SCIM 2.0 provider works, with no IdP-specific configuration beyond the standard base URL and token.

Connecting your IdP

As an account owner or admin, enable SCIM in your Wistia settings.
Copy the SCIM base URL and the generated Bearer token from the SCIM setup screen.
Paste both into your IdP's SCIM app configuration.

The base URL follows the form https://<your-domain>/scim. Authentication is a standard HTTP Authorization: Bearer <token> header. You can regenerate the token at any time if it's compromised; doing so invalidates the old one.

What SCIM manages

Provisions Users and Groups.
Supports create, update, and deactivate operations. PUT, PATCH, and DELETE map to replace, update, and deprovision.
Deactivating a user in your IdP (active = false) deprovisions them in Wistia.
Default provisioned role — new SCIM-provisioned users get a configurable default role (a standard user role unless you change it).
Deprovisioned content recipient — when a user is deactivated, their content is reassigned to a contact you designate. If you don't set one, it goes to the oldest account owner.
Optional email notifications for provisioning events.

SCIM is configured by an account owner or admin and is available on higher-tier and Enterprise plans; contact your account team to confirm availability.

Requirements

SSO and SCIM are configured by an account owner or admin.
SSO and SCIM are available on higher-tier and Enterprise plans — contact your account team to confirm availability.
SSO uses SAML 2.0 (SP-initiated). SCIM uses SCIM 2.0 with Bearer-token authentication.

Configure SSO and SCIM