Org sign-in policy

An organization owner can require how members sign in, and which email addresses they may use. Open Organization settings → Sign-in policy.

The two rules

The method list shows only the methods this organization can use: the Google, GitHub and Microsoft sign-ins the server has configured, plus SSO connections approved for this organization. Another organization's SSO connection never counts here.

An SSO sign-in counts only for addresses inside the connection's registered domains. An address from another domain signed in through the same identity provider is treated like any unverified sign-in.

A domain is a member restriction, not proof of employment: it checks the verified address on the account. On a server without email, password accounts cannot verify their address, so a domain rule admits only provider and SSO sign-ins that come with a verified address.

Who it applies to

The policy is checked on every request that acts on the organization:

• Browser sessions. A member who signed in another way sees the organization with a lock and the fix ("requires sign-in with Google"), with buttons to sign in that way or to link the provider. They keep their membership and can use their other organizations.
• CLI tokens are judged by how the browser session that approved thespider-agent login signed in. If that does not satisfy the policy, run thespider-agent login again and approve it while signed in with an allowed method.
• MCP authorizations are judged the same way, by the session that approved them. Re-authorize the MCP client after signing in with an allowed method.
• Enrollment (CI) tokens belong to no person and are not affected.
• New members. Invitations, invitation links and operator additions are refused for an address outside the allowed domains (email_domain_not_allowed). A refused invitation stays valid, so the person can verify their address and use the same link.

Nothing is removed when you turn a policy on: existing members and tokens stay, and start working again once they satisfy it.

Before you save

Preview impact lists the members who would be blocked and why, pending invitations that could no longer be accepted, and CLI or MCP tokens that would stop working. Saving is refused when:

• your own current session would not satisfy the policy (policy_would_lock_out_actor),
• no owner could sign in under it (no_compliant_owner), or
• it names a method this organization does not have (sign_in_method_unavailable).

Only owners can change the policy, from a browser, after a recent sign-in. While a policy is active, the last owner who can sign in under it cannot be demoted or removed (last_compliant_owner).

To turn the policy off, choose Turn off.

Plans

The domain list and requiring Google, GitHub or Microsoft are available on every plan. Naming an SSO connection in the policy needs Business, as do SSO connections themselves. If an organization moves off Business, its existing policy keeps applying unchanged; an SSO entry it already names shows "Requires Business to change" and can be removed but not added again.

When a method disappears

If the server stops offering a method (its credentials are removed) or an SSO connection's approval is revoked, a policy that needs it has nothing left to accept. The method rule is then suspended (the settings card says so, and its status reads Method rule suspended instead of On) while any domain rule still applies. Choose another method or turn the requirement off.

A method the policy names but this organization no longer has stays in the list, marked No longer available. Saving the policy removes it, and the card says so before you save.

Locked out

• Cloud: contact support. An operator can clear the policy for your organization.
• On-prem: run bun run src/auth-admin.ts clear-auth-policy on the server (add --org <slug> for an org other than the configured one), or set AUTH_POLICY_ENFORCEMENT=off and restart. Turn enforcement back on afterwards; the settings card warns while it is off.

SSO connections

SSO connections (OIDC or SAML) are set up by the operator: registered on the server and then approved for one organization. A connection signs nobody in until it is approved. See On-prem and the operator install guide.

See also Account security and the API reference.