Single sign-on

Overview

A space can name one identity provider, over OpenID Connect or SAML 2.0: Okta, Microsoft Entra ID, Google Workspace, or any provider that speaks either protocol. People who sign in through the issuer are created as accounts if needed, linked to the issuer's subject identifier, and added to the space at a configured role. The invitation gate does not apply to them; the space's own issuer is the invitation.

Setup

1. Open the space's Settings → Single sign-on. Copy the redirect URL shown there.
2. At the issuer, create a web application (OpenID Connect, authorization code) with that redirect URL and the scopes openid email profile.
3. Enter the issuer URL, the client ID and the client secret. Optionally enter the email domain the issuer covers, and the role new members receive.
4. Save. The page shows the space's sign-in door.

The issuer URL must match the issuer field of its discovery document exactly. The client secret is sealed with the space's secrets key, is never shown again, and is never injected into a CI job.

SAML

1. Under Settings → Single sign-on, choose SAML 2.0. The page shows the entity ID (also the metadata URL) and the assertion consumer service URL.
2. At the provider, create a SAML application with those two values, Name ID format email address, HTTP-POST binding for the response. Send the email address as the Name ID or as an attribute named email.
3. Download the provider's metadata XML and paste it into the form. Save.

Sigbound generates its own signing key and certificate for the space; the provider's metadata URL serves them. Responses are verified against the certificate in the provider's metadata, and each response must answer a request Sigbound made within the last fifteen minutes, once.

Signing in

On the sign-in page, Continue with your organisation accepts the space name, or a work address whose domain the space registered. The direct door is:

https://sigbound.com/auth/sso/<space>/start

Membership

A person who signs in through the issuer for the first time becomes a member of the space at the configured role, member or reader. Roles can be changed under Members afterwards. Removing the issuer closes the door; accounts and memberships remain.

Requiring the issuer

Require single sign-on for this space makes the space reachable only from a browser session that came through its issuer. A member signed in with a password or a one-time code is refused with sso_required and sent to the space's door. The setting can be turned on only from a session that came through the issuer, so an administrator cannot lock everyone out, including themselves. Personal API tokens and connected harnesses are not affected: they are issued by a person who already signed in, and an integration cannot be sent to an issuer.

Provisioning with SCIM

The identity provider can add and remove people itself over SCIM 2.0. Give it the space's base URL and a space token as the bearer; the provider then creates each person as an account, adds them to the space at the SSO role, and removes the membership when it deactivates them. The account is kept: a merge record that names a person keeps naming them.

Base URL   https://api.sigbound.com/orgs/<space>/scim/v2
Bearer     a space token from Settings → Credentials
Supported  Users: list, filter by userName or externalId, create, replace, patch, delete
           Groups: read as empty; roles are set in Sigbound

Deprovisioning removes the membership and marks the person inactive in the provider's view; a later reactivation restores the membership. userName is the person's email address and is not changed through SCIM.

Limits

• One issuer per space.
• Groups are not synchronised; roles are managed in Sigbound.