Single sign-on (SSO)

Organization admins can connect the organization's own identity provider (IdP) so members sign in with their company account. Setup lives in the portal under Settings → SSO:

1. Provider. Pick the IdP and paste the client ID and secret of an app you registered on the IdP side (Microsoft also needs the directory tenant ID).
2. Domain. Your email domain is claimed for the connection.
3. Test and activate. Run the connection test; once it passes, activate. For Microsoft, Test sign-in (below) also proves your domains. Only if your platform operator has enabled administrator verification is there an extra step first: a Verify with Microsoft/Google sign-in for Microsoft and Google, or a verified domain claim for other IdPs.

Until it is activated the tab shows the connection as Not active yet, with the next steps numbered (1. Test sign-in, 2. Activate). Once it is Active:

• Who can join. By default only people you invite can join. Anyone else who signs in with your IdP is told they are not a member of your organization yet and should ask an administrator for an invitation. An invited person joins on their first SSO sign-in.
• Automatic membership (off by default). Turn it on to let anyone who signs in with your IdP at your verified domains join as a Member. People you removed can't rejoin this way: they are listed under Settings → Members → Removed, where an administrator can Restore them (their previous role and projects come back when they next sign in; they get an email) or send them an invite.
• Require SSO. Everyone at your verified domains must sign in with your IdP; other sign-in methods are refused.
• Email address. Members are matched by their IdP account. Their email comes from the IdP's email claim; for Microsoft, an account without a mailbox uses its user principal name (UPN) when the UPN is at one of your proven domains. An account with no usable email is told to add one at the IdP or use another sign-in method. No extra form is shown after the IdP sign-in.

Members' own sign-in methods

Each person manages their own sign-in methods under Profile → Sign-in methods: their password, and Microsoft, Google or GitHub accounts connected to their portal account. Your SSO settings decide what they may change:

• Require SSO on: the page is read-only for everyone at your verified domains. It says, for example, "Managed by Acme: sign in with Acme Microsoft Entra ID"; nobody at those domains can connect a personal account, remove a method or add a password.
• Require SSO off: members may connect a personal Microsoft, Google or GitHub account and add a password, as long as the provider account uses the same email address as their portal account (verified by the provider). The provider your own connection uses (for example Microsoft for a Microsoft Entra connection) is not offered separately: those sign-ins go through your connection.
• Your SSO link shows on the page as managed by your organization; members cannot remove it.
• People whose address is not at your domains (guests you invited) are not affected by Require SSO.

Passwords. A password must have at least 12 characters (up to 128). Spaces and all characters are allowed, and there are no rules about capitals, digits or symbols. Common or leaked passwords, the person's own email address and their current password are refused. With Require SSO on, "Forgot password" at your domains sends no reset link: the person gets an email telling them to sign in with your SSO. People who sign in only with Microsoft, Google or GitHub get the same kind of email. Whenever a password is reset or changed, its owner gets an email saying so.

The IdP only accepts a sign-in if the address it sends the user back to is registered on your app, so register the redirect URIs below before members try to sign in.

Register redirect URIs

The Settings → SSO tab shows the exact values for your organization, with a copy button, for the IdP you picked. Copy them from there; the patterns below explain where each one comes from.

Every IdP type uses the same sign-in redirect URI (the SAML ACS URL is the same address):

<auth>/auth/realms/org/broker/org-<org-id>/endpoint

For example: https://auth.example.com/auth/realms/org/broker/org-0b6c2f8e-1d2a-4c3b-9e8f-7a6b5c4d3e2f/endpoint.

It is specific to your organization. It is not the redirect URI of the generic "Sign in with Google/Microsoft" buttons on the login page, and it is not <portal>/auth/oidc/callback.

No logout URL needs to be registered: signing out ends the session on this platform only and does not call your IdP's logout endpoint.

Microsoft Entra ID

Microsoft Entra admin center → App registrations → your app → Authentication → Add a platform → Web.

• Register the app in the same Microsoft tenant as your users' email domain. An app from another tenant (a parent company's, a partner's) does not work: Microsoft refuses it (AADSTS7000229) or your users sign in as guests. Settings → SSO warns when one of your domains belongs to a different tenant than the connection's.
• Supported account types: Accounts in this organizational directory only (single tenant).
• Create a client secret under Certificates & secrets and paste it, with the Application (client) ID and the Directory (tenant) ID, into Settings → SSO.
• API permissions (Microsoft Graph):
  • Delegated openid, profile, email and User.Read (the default on every app registration) — for sign-in. Admin consent is not required unless your tenant blocks user consent.
  • Application Organization.Read.All, then Grant admin consent — for domain proof (Test sign-in). Only a tenant administrator can grant it. Without it sign-in still works and you can still activate, but your domains are not proven.
• Token configuration: no optional claims are needed (adding email is harmless).
• If the app's enterprise application has Assignment required set to Yes, only the users and groups assigned to it can sign in through SSO.
• Verify with Microsoft appears only when administrator verification is enabled on the platform. It does not use your app: it signs you in through the platform's own Microsoft sign-in app, which returns to <portal>/auth/sso/verify-admin/callback. That URI is registered by the platform operator; do not add it to your app. If your tenant blocks user consent to third-party apps, an Entra administrator may need to grant consent to the platform's app the first time.

Test sign-in: prove your domains (Microsoft)

In Settings → SSO, Test sign-in signs you in once through your app (same redirect URI, nothing new to register). Use your own account — a member of the tenant, not a guest — whose email domain is one of the tenant's verified domains. With your app's own credentials the platform then reads your tenant's verified domains from Microsoft (Organization.Read.All, granted by your administrator) and claims them for your organization as proven:

• *.onmicrosoft.com is never claimed, and you can untick any domain.
• A domain another organization already claimed is shown as a conflict and is not taken; contact support to resolve it.
• At a proven domain nobody can sign up on their own or create another organization: they sign in with your SSO, or you invite them.
• If admin consent is missing, the result says "Ask your Microsoft administrator to grant admin consent for Organization.Read.All to this app, then test again." Nothing is claimed, but the test still counts for Activate.
• Changing the client ID or tenant ID clears the proof; run Test sign-in again.

Google Workspace

Google Cloud console → APIs & Services → Credentials → Create credentials → OAuth client ID → application type Web application.

• No authorized JavaScript origin is needed.
• Verify with Google appears only when administrator verification is enabled on the platform. It does not use your OAuth client: it signs you in through the platform's own Google client, which returns to <portal>/auth/sso/verify-admin/callback. That URI is registered by the platform operator; do not add it to your client. Sign in with a managed Google Workspace account on the claimed domain: personal Gmail accounts carry no domain and fail verification.

Okta and generic OIDC

Okta Admin Console → Applications → Create App Integration → OIDC - OpenID Connect → Web Application. For another OIDC provider, create a confidential client with the authorization-code flow.

• Grant type: authorization code. Scopes: openid, email, profile.
• Paste the issuer URL (for Okta https://<your-okta-domain> or https://<your-okta-domain>/oauth2/default), the client ID and the client secret into Settings → SSO.
• There is no IdP sign-in step for verification. Only when administrator verification is enabled on the platform does activation also require a verified claim of your email domain.

SAML

SAML connections are set up through the API rather than the portal wizard. Configure the service provider on your IdP with:

Use the user's email address as the NameID (format urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress). When administrator verification is enabled on the platform, activation also requires a verified claim of your email domain.

Troubleshooting