# Overview

Require visitor authentication before accessing a status dashboard.

Source: https://statusdashboard.com/docs/status-dashboards/sso/overview

> This is a plan-gated feature. If it isn't available in your account, visit the [Billing](/docs/org-mgmt/billing) page or contact support to review your options.

Dashboard SSO requires visitors to sign in through your identity provider before viewing a status dashboard. Use it for internal pages that should not be publicly readable.

***

## How it works
StatusDashboard supports per-dashboard **Single Sign-On (SSO)**, allowing you to restrict access to a status dashboard so that only authenticated users from your identity provider can view it. This is useful for internal status dashboards — for example, an engineering dashboard that should only be visible to your team.

When enabled on a dashboard, unauthenticated visitors are redirected to your identity provider to sign in before they can view the page.

Each dashboard can have at most **one** SSO provider configured. When a visitor navigates to a protected dashboard:

1. They are redirected to your identity provider to authenticate.
2. After successful authentication, they are redirected back to the dashboard.
3. The dashboard is displayed normally.

If authentication fails or the visitor cancels, they are returned to the sign-in page without access.

SSO can be **enabled** or **disabled** independently of whether a provider is configured. This lets you configure and test a provider before enforcing it for visitors.

## Supported protocols
| Protocol | Guide                                    |
| -------- | ---------------------------------------- |
| SAML 2.0 | [SAML](/docs/status-dashboards/sso/saml) |
| OIDC     | [OIDC](/docs/status-dashboards/sso/oidc) |

## Configuration
SSO is configured per dashboard in the **StatusDashboard admin console**:

1. Go to [Dashboards](/app/dashboards) and open the dashboard you want to protect.
2. Select **Single Sign-On**.
3. Choose your protocol (SAML or OIDC) and enter the provider details.
4. Save the configuration, then use the toggle to enable SSO for visitors.

## Enabling and disabling SSO
Saving a provider does **not** automatically protect the dashboard. SSO enforcement is controlled separately by a toggle. This means you can:

* Configure your identity provider without affecting current visitors.
* Test authentication before turning on enforcement.
* Temporarily disable SSO without losing your provider configuration.

> When SSO is enabled, visitors must authenticate through your identity provider to view **the status dashboard page**. There is no per-user exception for the main page.
>   The [embeddable widget](/docs/status-dashboards/widget) does **not** participate in SSO. Its script and status API remain publicly accessible (subject to your [IP allowlist](/docs/status-dashboards/network) if configured). Do not enable or embed the widget if you need all status data to stay behind SSO.

[Subscriptions](/docs/status-dashboards/subscriptions) add a second layer on top of SSO. Dashboard SSO controls who may reach the status dashboard; visitors must still complete the normal channel verification flow to subscribe or manage notifications, even when IdP login is required.

## Removing SSO
Deleting a provider removes the SSO configuration from the dashboard immediately. The dashboard reverts to being publicly accessible. This action cannot be undone — if you want to re-enable SSO later, you will need to re-enter your provider details.