Governance and security
SSO and directory sync
Sign in with your identity provider and provision users and groups from Entra ID, Okta, LDAP / Active Directory, Google Workspace or SCIM.
Single sign-on
How people sign in depends on the instance's auth provider (see Infrastructure: Auth):
- Supabase Auth (the default): enable the Azure (Microsoft) provider or SAML in your Supabase project, then set
NEXT_PUBLIC_SSO_MICROSOFT=1to show Sign in with Microsoft on the login page. - Built-in auth: email and password in UserTasks' own database plus any OIDC or SAML identity provider (Entra ID, Okta, Google, Keycloak, AD FS, …), and optionally LDAP bind login so people sign in with their directory password.
On the Microsoft app registration used for sign-in, add the email and xms_edov optional claims so Microsoft reports verified emails. That is what links a sign-in to the account directory sync created, instead of creating a duplicate.
Directory sync
Settings → SSO & Directory keeps the workspace's people and teams in step with your directory:
| Directory | How | Page |
|---|---|---|
| Microsoft Entra ID | pulled through Microsoft Graph (app registration with User.Read.All and GroupMember.Read.All) | this page |
| Okta | pulled through the Okta API (API token) | this page |
| LDAP / Active Directory | pulled over LDAPS or StartTLS with a service account; nested groups, delta sync | LDAP and Active Directory |
| Google Workspace | pulled through the Admin SDK Directory API (service account with domain-wide delegation) | Google Workspace |
| Any SCIM 2.0 identity provider | pushed by the IdP to /scim/v2 with a workspace token | SCIM provisioning |
Every directory follows the same rules:
- Matching: a directory user with an email links to the account with that email; otherwise, with Automatically create accounts on (the default), an account without a password is created — they sign in through SSO or LDAP. Users without an email are skipped.
- Access: linked users get an active membership in this workspace and the Member role (when they hold no role here yet).
- Leaving: a disabled or deleted directory user loses access on the next sync (SCIM: immediately) — the membership is deactivated and their roles here are removed, so their API keys and OAuth tokens stop working. The account itself is never deleted, and coming back restores access.
- Groups: with Sync groups as teams on, each directory group becomes a team and its membership is kept in step. Only members added by the directory are ever removed; people you added to the team by hand stay.
Pulled directories sync every hour by default (sync_interval_minutes, minimum 10, via the directory-sync job) and on demand; the page shows progress and history, and system.sync.directory.* events record each run. Credentials are encrypted, never shown again, and may be secret://tenants/<workspace id>/<name> references to the instance's secret store.
The same settings are available through the API (/api/v1/directory-sync), the CLI (usertasks directory-sync …, usertasks scim-tokens …) and MCP (directory_sync_*, scim_tokens_*).