Enterprise SSO

Signing in with a company account (OIDC) is available on the Enterprise plan. The SAML infrastructure is in place and is enabled on enterprise request.

Setup

  1. In your identity provider, create an application (Azure AD / Entra ID, Keycloak, Okta, Google Workspace…).

  2. Set this as the redirect address: https://api.errorbird.com/api/v1/auth/sso/callback

  3. Allow the openid email profile scopes. The email scope is required; users cannot be matched without an email.

  4. In the Errorbird dashboard, go to Compliance and security → Enterprise SSO → Add connection:

    Field Example
    Display name Example Inc. Entra ID
    Email domain example.com
    Provider address https://login.microsoftonline.com/<tenant>/v2.0
    Client id The application id at the provider
    Client secret The secret generated at the provider

  5. Enable the connection.

Why is a connection created disabled?

A new connection is disabled and does not change the sign-in path. A misconfigured SSO locks all of the company's users out, which is worse than having no SSO at all. Enabling is a separate, deliberate step, and it is refused if the configuration is incomplete.

Password sign-in stays on

When your identity provider is unreachable, the organization owner must still be able to get in (break-glass). That is why password sign-in keeps working while SSO is on.

How does sign-in work?

  1. The user types their email on the sign-in screen.
  2. The dashboard asks about the domain with POST /api/v1/auth/sso/discover.
  3. If the domain is bound to a connection, a "continue with company account" button appears.
  4. The user is redirected to the provider (authorization code + PKCE).
  5. On return, the id_token is validated with the provider's JWKS keys.
  6. If the user does not exist, they are created and added to the organization, and the session starts.

The flow's intermediate state is kept on the server and is single use: a captured callback address cannot be used a second time. It expires after 10 minutes.

Automatic user provisioning

With autoProvisionUsers on, a new user authenticated at the provider is created automatically and added to the organization with the default role. The default role cannot be Owner — if everyone signing in with SSO could take over the organization, the permission model would be meaningless.

With it off, only existing members can sign in; a new user gets the user_not_provisioned error.

Domain matching

The domain of the email returned by the provider must match the domain defined on the connection. Otherwise sign-in is refused with domain_mismatch: a provider can return a user of a domain it does not own, and letting that user into your organization would make the match meaningless.

An email domain can be bound to only one connection.

Audit

Creating, updating, enabling and disabling a connection, and every sign-in through SSO, are written to the audit trail. See KVKK and the data processing agreement.

SAML

A SAML connection can be defined, but the sign-in flow returns 501 and says explicitly that it has not been enabled on this installation. The reason is security, not technology: a SAML flow without signature validation means authentication can be bypassed entirely. If you have an enterprise requirement, contact us.