Skip to main content
SSO access puts your own login in front of a stream. Viewers are sent to your identity provider, sign in there, and come back to the stream only if they succeed. Streampixel never sees their password; it only receives the signed identity your provider issues. Use it when a stream is for your staff, your customers, or a partner organisation, and a shared password is not good enough.
SSO works with any provider that supports OpenID Connect: Microsoft Entra ID (Azure AD), Okta, Auth0, Google Workspace, Keycloak and others. It is an access control for viewers of a stream. It is separate from how you sign in to the dashboard.

​
How it fits with the other access controls

A project has one access mode. Password and SSO are alternatives: turning one on turns the other off. Domain restrictions work alongside either, and SSO requires them, see below.

​
Step 1: connect your identity provider

This is done once per account, under Settings → SSO. A connection can then be used by any number of projects.
  1. In your identity provider, create an OpenID Connect web application and register this redirect URL exactly:
  2. In Streampixel, open Settings → SSO and click Add connection. Fill in:
  1. Save. The connection appears in the list with its issuer.

​
Step 2: turn it on for a project

  1. Open the project and go to Project Settings.
  2. Under Domain restrictions, make sure at least one allowed domain is listed. SSO delivers a one-time sign-in grant to the page that embeds the stream, and that page must be one you trust. The dashboard refuses to enable SSO on a project with an empty list, with the message Add at least one allowed domain to the allowlist before enabling SSO.
  3. In the SSO Access card, choose your connection from the Identity provider dropdown. Off — no SSO switches it off again.
  4. Save.
With just these steps, any user who can sign in with that provider may view the stream, and Password protection is off for the project.

​
What viewers see

  1. The stream page shows a sign-in button instead of the stream.
  2. They are sent to your provider. If they are already signed in there, this can be instant.
  3. They land back on the stream and it loads.
If they are refused, they see Your account does not have access to this stream. A sign-in that took too long shows That sign-in link expired. Please try again. Both are safe to retry. The same gate applies to the private preview link in Test Locally, so you can check the experience before sharing anything.

​
Narrowing who gets in

These rules are part of the project’s SSO policy and are applied on every sign-in. They are not yet editable in the dashboard; ask support to set them for a project, or set them through the API.
Three lists can be attached to a project. All three are optional. How they combine:
  • A user on the allowed users list is always admitted, whatever the other lists say.
  • If neither domains nor groups are set, signing in is the only requirement. If only an allowed-users list is set, everyone else is refused.
  • If domains are set, the address must match one of them. A provider that explicitly marks an address as unverified is refused. Providers that simply do not report verification, which includes Microsoft Entra, are accepted; enable Require verified email on the connection if you want the strict behaviour.
  • If groups are set, the user must be in at least one.

​
Troubleshooting