OAuth 2.0
Social and enterprise OAuth providers: Google, GitHub, Microsoft, Okta, and Keycloak.
LDAP / Active Directory
LDAP authentication and automatic directory sync for on-premises identity stores.
SAML 2.0
SAML-based single sign-on with any SAML 2.0 compliant identity provider.
OAuth 2.0 providers
Collabase supports the following OAuth 2.0 providers out of the box:
| Provider | Notes |
|---|---|
| Standard Google OAuth. Works for both personal and Workspace accounts. | |
| GitHub | GitHub OAuth App. Requires creating an OAuth App in your GitHub organisation. |
| Microsoft | Microsoft / Azure AD OAuth. Works with personal accounts and Entra tenants. |
| Okta | Requires your Okta organisation domain URL. |
| Keycloak | Requires your Keycloak realm issuer URL. |
Configuring an OAuth provider
Create an OAuth application in your provider
Register a new OAuth app in your identity provider’s developer console. You will need to supply a redirect URI (callback URL).The callback URL for Collabase is:For example, for Google:
https://app.example.com/api/auth/callback/googleCopy your Client ID and Client Secret
Your provider will give you a Client ID and Client Secret once you create the app.
Open Settings → Identity Providers
Click the provider card (Google, GitHub, Microsoft, Okta, or Keycloak) in the Add Identity Provider section.
Enter your credentials
Paste the Client ID and Client Secret. For Okta, enter your Okta domain URL. For Keycloak, enter the full realm issuer URL including
/realms/<realm-name>.Set the default role
Choose the global role (Viewer, Collaborator, or Admin) that new users created through this provider will receive.
Client secrets are encrypted at rest and are never displayed again after saving. To rotate a secret, open the provider settings and enter a new secret.
LDAP / Active Directory
LDAP lets Collabase authenticate users against an on-premises or cloud LDAP server (OpenLDAP, Active Directory, FreeIPA, etc.) and periodically sync the user list. Navigate to Settings → Identity Providers and click the Active Directory / LDAP row to configure it.What you need
| Field | Description |
|---|---|
| Host | LDAP server hostname or IP address. |
| Port | Default 389 for plain LDAP, 636 for LDAPS (TLS). |
| Use TLS | Enable to connect over LDAPS. Automatically switches the port to 636. |
| Bind DN | The distinguished name of the service account Collabase uses to bind to the directory. Example: cn=svc-collabase,ou=service-accounts,dc=example,dc=com |
| Bind Password | Password for the bind service account. |
| Base DN | The root of the tree to search for users. Example: ou=users,dc=example,dc=com |
| User Search Filter | LDAP filter to select user objects. Default: (objectClass=person) |
| Email Attribute | LDAP attribute that maps to the user’s email. Default: mail |
| Name Attribute | LDAP attribute that maps to the user’s display name. Default: displayName |
| Groups Attribute | LDAP attribute used for group membership. Default: memberOf |
| Default Role | The global role assigned to users synced from LDAP. |
Directory presets
The configuration panel includes presets to auto-fill common attribute mappings:- Active Directory — uses
userPrincipalNamefor email,displayNamefor name,(objectClass=user)for filter. - OpenLDAP — uses
mailfor email,cnfor name,(objectClass=inetOrgPerson)for filter.
Testing the connection
Click Test Connection after filling in the server details to verify that Collabase can bind to your directory and count matching users before saving. The test result shows the number of users found or the error message if the connection fails.Sync behaviour
When LDAP sync is enabled, Collabase periodically pulls users from the directory:- New users in LDAP are created in Collabase with the configured default role.
- Existing users have their name and LDAP DN updated on each sync.
- Users removed from LDAP (no longer matching the search filter) are disabled in Collabase.
SAML 2.0
SAML 2.0 is supported for enterprise single sign-on with identity providers such as Okta, Microsoft Entra (Azure AD), and any other SAML 2.0 compliant IdP.What you provide to your IdP
Your identity provider needs two values to register Collabase as a service provider:| Value | Format |
|---|---|
| ACS URL (Assertion Consumer Service) | https://your-collabase-domain/api/auth/saml/callback |
| SP Entity ID | https://your-collabase-domain/api/auth/saml/metadata |
You can also point your IdP to the metadata URL directly:
https://your-collabase-domain/api/auth/saml/metadata. Most modern IdPs can import the SP metadata automatically from this URL.What you need from your IdP
| Field | Where to find it |
|---|---|
| IdP SSO URL | The Single Sign-On URL from your IdP. In Okta, this is the Identity Provider Single Sign-On URL. In Entra, it is the Login URL. |
| IdP Certificate | The X.509 certificate used by your IdP to sign assertions. Copy the PEM-encoded certificate from your IdP. |
| Entity ID | The IdP’s entity identifier (issuer). Usually a URL provided in your IdP’s SAML settings. |
Configuring SAML
Navigate to Settings → Identity Providers and open the SAML configuration panel.Attribute mapping
Collabase maps the following SAML assertion attributes to user profile fields:| Collabase field | Expected SAML attribute |
|---|---|
email or http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress | |
| Display name | displayName or name |
SSO bypass policy
When SSO is the primary authentication method for your organisation, you may still need certain admin accounts to be able to log in with a password — for example, a break-glass admin account. Configure this under Settings → Security → Policies → SSO Bypass:- Add specific users or groups that are exempt from the SSO requirement.
- Generate a bypass link (
/auth/login?sso_bypass=1) that bypasses SSO enforcement and shows the standard email/password login form.