Single sign-on lets your team sign in to Doxbrix with your existing identity provider (IdP) — Okta, Microsoft Entra ID, Google Workspace, and many more — instead...
Single sign-on lets your team sign in to Doxbrix with your existing identity provider (IdP) — Okta, Microsoft Entra ID, Google Workspace, and many more — instead...
Single sign-on lets your team sign in to Doxbrix with your existing identity provider (IdP) — Okta, Microsoft Entra ID, Google Workspace, and many more — instead of separate Doxbrix passwords. You connect your IdP once, verify your email domain, then optionally require everyone to use it.
Doxbrix supports both OIDC (OpenID Connect) and SAML 2.0, with one-click presets for the major providers plus generic connectors for anything else.
Supported identity providers
Each provider below appears in the Single Sign-On section as a tile with its logo. Pick yours and follow the inline hints — or use Generic OIDC / Generic SAML 2.0 for any standards-compliant IdP.
| Provider | Protocol |
|---|---|
| 🟦 Okta | OIDC |
| 🔵 Google Workspace | OIDC |
| 🟧 Auth0 | OIDC |
| ⬛ OneLogin | OIDC |
| 🟦 Microsoft Entra ID | OIDC |
| 🟥 Ping Identity | OIDC |
| ⬛ JumpCloud | OIDC |
| ⬜ Keycloak | OIDC |
| 🔵 Salesforce Identity | OIDC |
| 🟥 Oracle Identity | OIDC |
| 🟩 Duo SSO | SAML |
| 🟧 AWS IAM Identity Center | SAML |
| 🟦 CyberArk Identity | SAML |
| ⬛ AD FS (Active Directory Federation Services) | SAML |
| 🟪 Shibboleth | SAML |
OIDC or SAML?
| Col 1 | OIDC | SAML 2.0 |
|---|---|---|
| **Best when** | Your IdP offers an OIDC/OpenID Connect app | Your IdP only offers SAML, or policy requires it |
| **You give Doxbrix** | **Issuer URL**, **Client ID**, **Client secret** | **IdP metadata URL** (or XML) |
| **You give your IdP** | The **Redirect / callback URL** | The **ACS URL** |
Most modern providers support OIDC, which is simpler to set up. The preset you pick already selects the right protocol.
Before you begin
- An Enterprise workspace, and Owner or Admin access to it.
- Admin access to your identity provider to create an application.
- The email domain your team signs in with (e.g.
acme.com) and the ability to add a DNS TXT record to verify it.
Configure SSO
Setup has three phases — connect, verify the email domain, then require SSO — matching the Single Sign-On settings section.
1. Connect your identity provider
Go to Settings → Workspace → Single Sign-On and choose Connect an identity provider. Pick your provider's tile, or Generic OIDC / Generic SAML 2.0 if it isn't listed.
Copy the Redirect / callback URL (OIDC) or the ACS URL (SAML) shown on the tile — you'll paste this into your IdP.
In your identity provider, create a new app of the matching type (an OIDC web app, or a SAML service provider) and paste the URL from the previous step into its sign-in redirect / ACS field.
Back in Doxbrix, set the Connection name and Email domain, then enter the provider fields — for OIDC the Issuer URL, Client ID, and Client secret; for SAML the IdP metadata URL or IdP metadata XML.
2. Verify the email domain
The Email domain routes anyone with an address on it to your provider at sign-in. Doxbrix asks you to prove you own it:
Doxbrix shows a DNS TXT record with a Host and Value. Add it at your DNS provider.
Click Check DNS. Once the record is found, the domain is verified.
3. Require SSO (optional)
Once a provider is connected and its domain verified, turn on Require SSO:
Form fields
These are the exact fields on the connection form.
Connection
| Field | Required | What it is |
|---|---|---|
| **Connection name** | Yes | A label for this connection in your workspace. |
| **Email domain** | Yes | Users with this email domain are routed to this provider at sign-in (e.g. `acme.com`). |
OIDC fields
| Field | Required | What it is |
|---|---|---|
| **Issuer URL** | Yes | Your IdP's issuer, e.g. `https://acme.okta.com`. Doxbrix discovers the OIDC endpoints from it. |
| **Client ID** | Yes | The client identifier of the OIDC application you created in your IdP. |
| **Client secret** | Yes | The application's client secret. Stored encrypted; never exposed to readers. |
| **Discovery URL (optional)** | No | Override the OpenID configuration document URL. Defaults to the issuer plus `/.well-known/openid-configuration`. |
| **Scopes (optional)** | No | Space-separated scopes to request. Defaults to `openid email profile`. |
SAML fields
| Field | Required | What it is |
|---|---|---|
| **IdP metadata URL** | One of these two | The URL where your IdP publishes its SAML metadata. Preferred — Doxbrix keeps it in sync. |
| **IdP metadata XML** | One of these two | Paste the metadata XML directly if your IdP only offers a downloadable file. |
| **Email attribute (optional)** | No | The assertion attribute holding the user's email. Falls back to the SAML `NameID` if omitted. |
| **Name attribute (optional)** | No | The assertion attribute holding the display name, e.g. `displayName`. |
| **Role attribute (optional)** | No | The assertion attribute carrying the user's role or group — used for [group mapping](#group-and-role-mapping). |
Values Doxbrix provides
Shown on the connection form for you to copy into your IdP:
| Value | Protocol | Paste it into |
|---|---|---|
| **Redirect / callback URL** | OIDC | Your OIDC app's *sign-in redirect URIs*. |
| **ACS URL** | SAML | Your IdP's *Assertion Consumer Service (ACS)* URL. |
| **DNS TXT record** (Host / Value) | Both | Your DNS, to verify the **Email domain**. |
Worked example: Okta (OIDC)
In the Okta Admin Console, go to Applications → Create App Integration and choose OIDC – OpenID Connect with Web Application.
Paste Doxbrix's Redirect / callback URL into Okta's Sign-in redirect URIs.
After saving, copy the Client ID and Client secret into Doxbrix, and set the Issuer URL to your Okta org URL (e.g. https://acme.okta.com).
Worked example: SAML (e.g. Duo)
In your IdP, add a generic SAML service provider (for Duo: Applications → Generic SAML Service Provider).
Paste Doxbrix's ACS URL into the service provider's ACS / Assertion Consumer Service field. If the IdP asks for an SP Entity ID and you have no separate value, use the ACS URL.
Set the IdP metadata URL, or download the metadata file and paste it into IdP metadata XML.
Group and role mapping
SSO can map your IdP's groups to Doxbrix access. With OIDC, group claims come from the token; with SAML, they come from the Role attribute (optional) field. Map those groups to:
- Member roles — so directory groups grant Editor, Writer, Reviewer, etc.
- Audience groups — for reader-facing private docs, so each reader sees only what their group permits.
SCIM provisioning
On Enterprise plans, you can pair SSO with SCIM so member lifecycle is automatic — accounts are provisioned and deactivated in Doxbrix as people join and leave in your directory, and group membership stays in step. Removing someone in your IdP revokes their Doxbrix access automatically.
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| Redirect / login loop | Redirect or ACS URL mismatch | Re-copy the exact **Redirect / callback URL** or **ACS URL** into your IdP |
| "Invalid client" (OIDC) | Wrong client ID/secret or issuer | Re-check **Client ID**, **Client secret**, and **Issuer URL** (no trailing slash) |
| Assertion rejected (SAML) | Metadata out of date | Use the **IdP metadata URL** so it stays current, or re-paste fresh **IdP metadata XML** |
| Domain won't verify | DNS TXT record not propagated | Confirm the **Host**/**Value** match exactly, then click **Check DNS** again |
| User has no email | Email attribute not mapped | Set the **Email attribute (optional)**, or ensure the IdP sends it in the `NameID` |
| Wrong role after login | Group/role claim not mapped | Map the IdP group via the **Role attribute (optional)** / group mapping |