Single sign-on (SAML)

How SSO works on Spaceboy

Spaceboy supports SAML 2.0 single sign-on with any identity provider — Okta, Microsoft Entra ID, Google Workspace, and others. Sign-in routes by email domain: once your organization has verified a domain and connected an IdP, anyone choosing Continue with SSO and entering an address on that domain is handed to your IdP to authenticate. Members are provisioned on their first SSO sign-in, so onboarding is just assigning the app in your IdP — no invites required for authentication itself.

Setup lives at Organization settings → Single Sign-On and takes three steps, each self-serve: verify a domain, connect your IdP, and (optionally) enforce SSO. Owners and admins can configure it; every configuration change is written to the audit log under the Identity category.

Step 1 — Verify your email domain

First, prove you own the domain your team's email addresses use. Add the domain on the SSO settings page and Spaceboy issues a DNS TXT challenge — create the record with your DNS provider, then choose Verify. The settings page presents the record exactly like this, with your real domain and token, each field ready to copy:

DNS changes can take a few minutes to propagate; if verification fails, wait and retry. A domain can be claimed by exactly one organization — verifying it is what authorizes attaching it to your identity provider, and what scopes SSO enforcement to your people.

Step 2 — Connect your identity provider

Create a SAML app for Spaceboy in your IdP (the per-provider guides below walk through it), then register it on the SSO settings page by pasting its SAML metadata — either the metadata URL your IdP hosts, or the raw metadata XML for providers that only offer a download. Spaceboy reads the signing certificate and endpoints from the metadata; there are no certificates to copy by hand, and re-submitting the metadata later updates the connection in place.

Step 3 — Test sign-in

On the sign-in page, choose Continue with SSO and enter a work email address (or just the domain). Spaceboy looks up the identity provider for that domain and redirects to it; after your IdP authenticates, you land back in Spaceboy signed in. Test with your own account before enforcing anything.

Enforcing SSO

Once the connection works, you can require it. With Enforce SSO on, members whose email is on a verified domain must sign in through your identity provider — password and social sign-ins are refused for them. Combined with your IdP, this closes the loop on offboarding too: someone removed from the IdP can no longer authenticate to Spaceboy where SSO is enforced.

Organization owners are always exempt from enforcement, so a misconfigured IdP can never lock the organization out. The exemption applies to owners only — admins and members on verified domains are held to SSO.

Auditing

Every identity-configuration change — domains added, verified, or removed; the provider configured or disconnected; enforcement toggled — lands in the audit log under the Identity category, so your security team can reconstruct exactly when and by whom sign-in policy changed.