Single Sign-On Overview

Organization SSO lets your team sign in to the admin console with your corporate identity provider instead of a StatusDashboard password. StatusDashboard supports SAML 2.0 and OIDC; Sign in with Google is also available on all accounts and works independently of enterprise SSO.

Admins configure providers on the Single Sign-On page and map them to email domains. The sections below compare Google sign-in and enterprise SSO, explain the login flow, and link to protocol-specific setup guides.

---

Google sign-in

StatusDashboard supports two distinct sign-in modes beyond username and password: Google sign-in (built in for all accounts) and enterprise SSO via SAML or OIDC (available on plans with the SSO feature).

These are independent. You do not need the SSO feature to use Google sign-in, and configuring a SAML or OIDC provider does not affect how Google sign-in works.

A Sign in with Google button is available on the StatusDashboard login page for all users — no admin setup or SSO entitlement required.

• New users can sign up by clicking the Google button. StatusDashboard creates their account and organization automatically on first sign-in.
• Existing email/password users can link their Google account by clicking the Google button and completing the OAuth flow. Once linked, they can sign in with either method.
• Invited users — if an admin invited you to an existing organization and you sign in with Google for the first time, StatusDashboard links your Google identity to the invited account automatically. You will see a one-time confirmation prompt and need to click Sign in with Google once more to complete the flow. See First-time sign-in for invited users below.

See Google sign-in for details and important caveats about identity linking.

Enterprise SSO (SAML / OIDC)

Enterprise SSO lets your team sign in using your organization's identity provider — such as Okta, Azure AD, or any SAML 2.0 or OIDC-compatible IdP.

Unlike Google sign-in, enterprise SSO providers are configured by an admin in the SSO Providers section of the StatusDashboard dashboard. Each provider is mapped to one or more email domains. When a user enters their email at login, StatusDashboard checks the domain and redirects them to the matching provider.

Key differences from Google sign-in

• SAML/OIDC users must be invited by an admin before their first login. A new user who attempts to sign in via an enterprise SSO provider without an existing invitation will be blocked.
• If enterprise SSO is not on your plan, the SSO Providers section is not accessible.

Email domain uniqueness

Each email domain can only be assigned to one SSO provider at a time, globally across all of StatusDashboard. This applies in two ways:

• Within your organization — you cannot assign the same domain (e.g. acme.com) to both a SAML provider and an OIDC provider simultaneously. Each domain can only route to one provider.
• Across organizations — if another StatusDashboard organization has already claimed acme.com, your organization cannot use that domain in an SSO configuration.

Each provider requires at least one email domain. Your organization also has a maximum number of domains per provider — usage is shown when you add or edit a provider, and the API returns a clear error when that limit is reached. Reach out to support if you need a higher limit.

If you attempt to save a provider with a domain that is already in use, StatusDashboard will return an error. Reach out to support if you believe a domain has been claimed incorrectly.

Identity linking across multiple providers

A single StatusDashboard account can be linked to more than one sign-in method. This happens automatically when the same email address appears in multiple identity providers.

Example: A user whose StatusDashboard account email is tom@acme.com has previously signed in with Google. If your organization later configures a SAML provider (e.g. Okta or OneLogin) and tom@acme.com exists in that directory too, StatusDashboard will link the SAML identity to the same account on first SAML sign-in. From then on, tom@acme.com can authenticate via Google or via the SAML provider interchangeably.

This linking happens silently — neither the user nor the admin receives a notification.

What this means in practice

• A user with both Google and a corporate SSO identity at the same email address will end up with a single StatusDashboard account linked to both. This is usually the desired behavior.
• Because linking is email-based, it is important that your identity providers agree on the canonical email address for each user. If the same person has different email formats in different providers (e.g. tom@acme.com vs. thomas@acme.com), they will end up with separate StatusDashboard accounts.
• Linked identities cannot be unlinked through the admin console. If an incorrect link is made, the only recovery path is to delete the user and re-invite them.

Limitation: Google sign-in accounts and enterprise SSO

Enterprise SSO (SAML/OIDC) is designed for company-managed domains registered in your SSO provider configuration (e.g. acme.com). It is not compatible with accounts that were created via the Sign in with Google button.

If the account owner signed up for StatusDashboard using Google sign-in (e.g. tom@acme.com via Google OAuth), and later configures a SAML or OIDC provider whose directory also contains tom@acme.com, that account cannot sign in via the enterprise SSO provider. The SSO domain validation guard will block the attempt because the email's domain must be registered to an SSO provider in StatusDashboard — and a Google sign-in account, even on a company domain, is not the same as an enterprise SSO identity.

In practice this scenario does not arise for normal use: the account owner who sets up the organization typically uses Google sign-in for their own access, while enterprise SSO is configured for the rest of the team on a company domain. If you need the account owner's email to work with enterprise SSO as well, invite them as a user in StatusDashboard and they will be able to link their SSO identity on first sign-in.

First-time sign-in for invited users

When an admin invites a user to an existing organization, StatusDashboard pre-creates that user's account before they ever log in. The first time the invited user authenticates — whether via Google, SAML, or OIDC — StatusDashboard needs to link their provider identity to that pre-created account. This linking step causes a one-time redirect back to the login page. This is expected behavior — it is not an error.

What is happening: StatusDashboard detects the provider identity, links it to the user's existing invited account, and redirects back to the login page to complete the flow cleanly. The login page displays a confirmation message:

Your account has been linked. Sign in again using the same method you just used — Google or SSO — to continue.

The user simply signs in the same way a second time and is taken into the admin console normally. All subsequent logins go through without interruption.

This one-time redirect only occurs on the very first sign-in for an invited account. If you are rolling out SSO or inviting users who plan to use Google, it is worth letting them know in advance so they are not surprised by the redirect.

Deleting a provider with active users

Deleting an SSO provider is immediate and affects all users who relied on it.

What happens at deletion:

• The provider and its domain mappings are removed from StatusDashboard immediately. The domains become available for reuse.
• The identity provider configuration is removed from StatusDashboard.
• StatusDashboard user accounts for affected members are not deleted — only the sign-in path is severed.

Impact on users:

• Any user whose only sign-in method was the deleted provider is locked out immediately. They have no password and no alternative sign-in path.
• Users who also have native password login enabled (see Break Glass Access) can continue to sign in with their password and are unaffected.

If you recreate the provider: Recreating a provider with the same configuration generates a new internal provider identity — StatusDashboard cannot reuse the old one. Existing users' SSO links are orphaned and do not automatically reconnect.

However, access does self-heal: when a previously linked user attempts to sign in via the new provider, StatusDashboard detects their existing account by email address and re-links the new provider to it. The user will see a brief error on their first sign-in attempt and must retry — on the second attempt they are signed in successfully.

This means recreating a provider restores access for all affected users without requiring admin intervention, but it is not seamless. Users should be informed to expect the one-time retry.

Seat limits and provisioning

Neither Google sign-in nor enterprise SSO bypasses seat limits.

• Google sign-up (new org) — the account owner counts as 1 seat. Sign-up is not blocked by a seat quota check.
• Enterprise SSO (existing org) — if your plan's user quota is reached, new members who attempt to sign in via SSO for the first time will be blocked. An admin must free a seat or reach out to support before new members can access the organization.

Users who already have an account (created by invite or previous sign-in) are never affected by this limit — they can always sign in.

Emergency access

If Google or your identity provider becomes unavailable, users who rely exclusively on those methods will be locked out. StatusDashboard supports designating a break glass account — a specific user with native password login enabled — for emergency access.

See Break Glass Access for requirements and setup instructions.