Skip to main content
Collabase supports several sign-in methods. You can mix and match — for example, enable Microsoft Entra ID for most users while keeping email/password available as a fallback.
Using Microsoft Entra ID? The guide IAM with Microsoft Entra ID takes you through sign-in and SCIM from the first setting in Entra to the first test.
This feature is part of Collabase Enterprise Edition.
The Identity Providers page with the providers you can add and the SCIM Provisioning card

The Identity Providers page: add a provider, then connect SCIM below.

Configure identity providers under Admin → Identity Providers.

Email & Password

Always available. Users sign in with an email address and password set by an admin or chosen during registration.

OAuth 2.0

Sign in with Google, GitHub, Microsoft Entra ID, Okta, or Keycloak using an existing account. Users click a button on the login page.

SAML 2.0

Single sign-on with Okta, Microsoft Entra, or any SAML 2.0-compatible identity provider.

LDAP / Active Directory

Authenticate against your on-premises directory. Users sign in with their company credentials.

SCIM 2.0

Automated user and group provisioning from your identity provider. Accounts are created and deactivated automatically.

​
Email and password (always on)

Email and password authentication is always enabled and cannot be turned off. It is available at /auth/login even when other sign-in methods are active.
Keep at least one admin account using email and password. If your identity provider goes down or is misconfigured, this is how you recover access.

​
OAuth 2.0

OAuth lets users sign in with an existing account from another service — Google, GitHub, Microsoft Entra ID, Okta, or Keycloak. No passwords are stored in Collabase for OAuth users.

​
Setting up Google OAuth

1

Create an OAuth application in Google Cloud Console

Go to APIs & Services → Credentials → Create Credentials → OAuth client ID. Choose Web application as the application type.
2

Add the redirect URI

Under Authorized redirect URIs, add:
3

Copy the Client ID and Client Secret

Google shows these after you save the OAuth client.
4

Open Admin → Identity Providers → Google

Paste the Client ID and Client Secret into the corresponding fields.
5

Set the default role for new users

Choose User (recommended) or Admin. This role is assigned when a user signs in via Google for the first time and a new Collabase account is created.
6

Enable and save

Toggle the provider to Enabled. The Sign in with Google button appears on the login page immediately.

​
Setting up GitHub OAuth

1

Create an OAuth App on GitHub

Go to GitHub → Settings → Developer settings → OAuth Apps → New OAuth App.
2

Set the authorization callback URL

3

Copy the Client ID and generate a Client Secret

After saving, generate a client secret and copy both values.
4

Open Admin → Identity Providers → GitHub

Paste the Client ID and Client Secret.
5

Set the default role and enable

Choose the role for new users and toggle the provider to Enabled.

​
Setting up Microsoft Entra ID

1

Register an application in the Microsoft Entra admin center

Go to Identity → Applications → App registrations → New registration. Give it a name (e.g. “Collabase”).
2

Add the redirect URI

Under Authentication → Add a platform → Web, add:
3

Create a client secret

Go to Certificates & secrets → New client secret. Copy the secret value immediately — it is not shown again.
4

Copy the Application (client) ID and Directory (tenant) ID

Both are shown on the app registration’s Overview page.
5

Open Admin → Identity Providers → Microsoft

Enter the Client ID, Client Secret, and Tenant ID (Directory ID).
6

Set the default role and enable

Choose the role for new users and toggle the provider to Enabled.
Tenant ID is required for Microsoft Entra ID. Collabase will not save a Microsoft provider without one. This deliberately prevents sign-in from Microsoft accounts outside your organization — leaving the tenant unset would allow any Microsoft account in the world to sign in. Enter the Tenant ID as the ID (a GUID such as 0b6f1a2c-…), not as a domain name; a provider with a domain name cannot be used to sign in.

​
Setting up Okta or Keycloak

1

Register Collabase as an application

In Okta or Keycloak, create a new OIDC application. Use:
or
as the redirect URI, depending on the provider.
2

Copy the Client ID and Client Secret

Your provider shows these after the application is created.
3

Open Admin → Identity Providers → Okta or Keycloak

Enter the Client ID and Client Secret, plus:
  • Okta: your organization URL (e.g. https://mycompany.okta.com)
  • Keycloak: your realm issuer URL (e.g. https://keycloak.example.com/realms/myapp)
4

Set the default role and enable

Choose the role for new users and toggle the provider to Enabled.

​
Restricting sign-in by email domain

Every OAuth provider has an Allowed email domains field and an Auto-create new users toggle.
Set Allowed email domains for every provider except perhaps GitHub. Without it, anyone with an account at that provider can sign in and, if the setting above is on, get a new Collabase account. This is especially important for Microsoft, Okta, and Keycloak, where organizations are often shared across companies.

​
How existing accounts are linked

When someone who already has a Collabase account signs in with a provider for the first time, Collabase links the two accounts, but only if all of the following are true:
  • The provider is tied to your organization: Microsoft Entra ID with a Tenant ID, Okta or Keycloak with an issuer URL, or Google with a Google Workspace domain that matches the email address. GitHub never links an existing account.
  • The provider does not report the email address as unverified.
  • If you set Allowed email domains, the domain is on the list.
  • Exactly one active account has that email address, and it is not a guest.
The person then receives an email telling them the account was linked, and the link is recorded in the audit log. Later sign-ins use the provider’s own account ID, so a changed email address does not create a second account. If the provider reports an address that another Collabase account already uses, Collabase keeps the stored address and records the conflict in the audit log. If one of the conditions is not met, the person sees a message on the sign-in page and no account is linked or created. They can ask an administrator, or sign in with their password.
Providers that are already set up keep working after your Enterprise license expires, so nobody is locked out. You cannot add or change providers until the license is renewed.
Credentials are stored encrypted and cannot be viewed again after saving. To update a credential, enter the new value and save — the old value is replaced.

​
SAML 2.0

SAML 2.0 lets users sign in with Okta, Microsoft Entra, or any SAML 2.0-compatible identity provider. Once set up, users click Sign in with SSO on the login page and are redirected to your identity provider.
The page SAML single sign-on describes every setting, the account matching and the troubleshooting in detail.

​
What to give your identity provider

Your identity provider needs these two values to register Collabase as a service provider: Most providers can import the full configuration by fetching the metadata URL automatically. Collabase only accepts a response that answers a sign-in it started, so sign-in always begins at Collabase; logins started from the identity provider’s own portal are refused.

​
What you need from your identity provider

​
Configuring SAML

1

Open Admin → Identity Providers and choose SAML 2.0

Under Add an identity provider, click SAML 2.0. The panel holds the settings Collabase needs from your IdP and lists the ACS URL and metadata URL your IdP needs, as described under What to give your identity provider above.
2

Register Collabase in your identity provider

Use the ACS URL and Entity ID from the table above. Configure your IdP to send the member’s email address in an attribute named email and the display name in an attribute named displayName, and to sign the assertion. Collabase reads exactly these names and refuses an assertion that is not signed. Without an email attribute it uses the name identifier as the email address. For Microsoft Entra ID, see IAM with Microsoft Entra ID.
3

Enter the IdP SSO URL, certificate, and Entity ID in Collabase

Paste the values from your identity provider into the corresponding fields. If your provider publishes a metadata URL, enter it under Import from metadata URL and click Import: Collabase fills in the Entity ID, SSO URL, and certificate. Check the values, then continue. Only public HTTPS addresses are accepted.
4

Choose the default role

Choose the role new accounts get, and whether Collabase creates an account on a person’s first sign-in.
5

Enable and save

Toggle SAML to Enabled. Users see a Sign in with SSO button on the login page.

​
LDAP / Active Directory

LDAP connects Collabase to your on-premises directory (Active Directory, OpenLDAP, FreeIPA, etc.) for authentication and user provisioning. Users sign in with their existing company username and password. Navigate to Admin → Identity Providers → LDAP.

​
Configuration fields

The panel includes preset configurations for Active Directory ((objectClass=user), userPrincipalName, displayName) and OpenLDAP ((objectClass=inetOrgPerson), mail, cn) that fill in the common attribute mappings automatically. Click Test Connection to verify that Collabase can reach your directory before saving.
A Groups Attribute field is available for future use. Group membership is not yet synchronized from your directory — group membership must currently be managed in Collabase directly.

​
Directory sync

When Enable auto sync is on and a Sync Interval is set, Collabase automatically imports users from your directory on that schedule:
  • New users in the directory are created in Collabase.
  • Existing users have their name updated on each sync.
  • Users removed from the directory are disabled in Collabase — their content is not deleted.
  • A user who returns to the directory is enabled again, unless an administrator disabled that account by hand. A manual lock stays until an administrator lifts it.
  • The last active administrator is never disabled by a sync. If the directory no longer lists that account, it stays active and the sync result says so.
  • Synced users get no password from Collabase. They sign in with single sign-on, or with a password an administrator sets.
Click Sync Now to trigger a manual sync at any time, in addition to the schedule.
If a sync would disable an unusually large number of users, Collabase stops and asks you to confirm. This protects you if the directory connection is misconfigured or briefly unreachable — for example, a broken search filter that only matches a fraction of your real users. Review the warning message carefully before choosing Sync anyway; only proceed if you expect that many users to have genuinely left the directory.
Every new or re-enabled user takes one place of your licensed user limit. When no place is left, the sync skips the remaining users and reports how many it skipped. The next sync adds them once you have raised the limit or freed places.
If your Enterprise licence expires, directory sync stops: Sync Now answers with a licence error and the scheduled sync does nothing. Existing accounts and sign-in are not affected. Sync resumes as soon as the licence is renewed.
A sync that finds zero users in your directory is always stopped automatically and cannot be forced through — this is treated as a configuration problem, not a real empty directory.

​
SCIM 2.0 automated provisioning

SCIM (System for Cross-domain Identity Management) connects your identity provider to Collabase so user accounts — and their group memberships — are created, updated, and deactivated automatically.
The page User provisioning with SCIM lists the supported operations for accounts and groups and the troubleshooting steps.

​
Enabling SCIM

1

Open Admin → Identity Providers

Scroll to the SCIM Provisioning section.
2

Toggle Enable SCIM provisioning

SCIM requests are rejected until this is on, even with a valid token.
3

Click Generate token

Copy the token immediately. Collabase shows it only once. A token is valid for 365 days.
4

Configure your identity provider

In your IdP’s SCIM settings, enter:
  • SCIM base URL: https://your-collabase-domain/api/scim/v2
  • Authentication method: Bearer token
  • Bearer token: the token you just copied
5

Assign the Collabase application to your users and groups

In your IdP, assign the Collabase SCIM application to the users or groups that should have access. The IdP pushes those users and groups to Collabase automatically.
6

Verify provisioning

Check Admin → Users to confirm the expected users were created. The Identity column on each user row shows the account’s origin.
The SCIM token is shown only once. If you lose it, click Generate token again: the new token replaces the old one, and the old one stops working immediately. Update your identity provider with the new token before its next sync. Generate a new token before the current one reaches 365 days.

​
What SCIM syncs automatically

SCIM does not delete accounts — it only deactivates them. Content created by the user is preserved.

​
How users and groups are matched

  • No matching by email. If your IdP sends a user whose email address already belongs to a Collabase account that SCIM has not created, Collabase rejects the user with a conflict (HTTP 409) and records the rejection in the audit log as SCIM_USER_REJECTED. Resolve it by changing the email address of one of the two accounts, then let the IdP try again.
  • Matching by the IdP’s own ID. A user whose external ID is already stored on a Collabase account is linked to that account. Name and email address then follow your IdP.
  • Deactivation by an administrator stays. If an administrator deactivated an account in Admin → Users, a later “active” message from your IdP does not reactivate it.
  • No free licence seat. When the licensed user limit is reached, new users and reactivations are rejected with HTTP 403.

​
Users that were turned away

Below the token list, the SCIM Provisioning card shows Recently turned away: the last ten users your IdP tried to create and Collabase refused, with the reason and the time. The reason is either that the email address already belongs to another account or that no licensed seat was free. Fix the cause, and the next provisioning run of your IdP takes the user in.

​
Groups

Groups pushed by SCIM become Collabase groups. Their members follow your IdP, so you cannot add or remove members, rename, or delete these groups in Collabase. You can still give them access to spaces. A group with the same name as an existing Collabase group takes over that group; its members are replaced by the members from your IdP. A group can have at most 1,000 members.

​
Updating from an earlier version

Tokens created before this update no longer work. Open Admin → Identity Providers → SCIM Provisioning, click Generate token, enter the new token in your IdP, and restart provisioning there once (in Microsoft Entra ID: Restart provisioning). Users who already have an external ID in Collabase are linked again instead of being created twice.
SCIM stops when the Enterprise licence has expired: requests are answered with HTTP 403 until the licence is renewed.

​
Emergency admin access

Always keep at least one admin account that can sign in with email and password — in case your identity provider is unavailable. The email/password login page is always accessible at /auth/login, even when SSO is the default sign-in method for all other users. Accounts you exempt from enforced single sign-on (by name or through a group in the SSO bypass policy) must have a second sign-in step before you can enforce SSO. If one of them signs in with a password only, Collabase refuses to save and names the accounts. Ask them to set up an authenticator app or a passkey first.
If every admin account relies exclusively on an external provider (Google, Microsoft, SAML, LDAP) and that provider goes down or is misconfigured, you will be locked out of the admin panel. Maintain one local admin account as a recovery option.
Last modified on October 13, 2026