Set up SSO so your team signs in to BeforeQuery through your identity provider instead of managing separate passwords. Connections are configured per workspace and routed by email domain: when a user starts SSO with [email protected], BeforeQuery finds the connection registered for acme.com and redirects to the right IdP. On successful sign-in, the user is found-or-created, auto-joined to the workspace, and issued a normal session.
You must verify your domain before sign-in works. A connection routes nobody until its DNS record is published, and BeforeQuery refuses any identity your IdP returns from outside the connection’s domain.
Social login (Google, GitHub) is available to all accounts out of the box — SSO connections are for enterprise IdPs. Both OIDC and SAML 2.0 are Enterprise-only.

​
Set up OIDC

Works with any spec-compliant OIDC provider — Okta, Microsoft Entra ID, Google Workspace, Auth0, Keycloak, and others.
1

Create an application in your IdP

Register a web application and note its issuer URL, client ID, and client secret. Set the redirect URI your IdP asks for to BeforeQuery’s SSO callback (shown in the dashboard when you create the connection).
2

Add the connection in BeforeQuery

As a workspace owner, open Workspace → Settings → SSO and click Add connection. Choose OIDC, then enter the issuer URL, client ID, client secret, and your email domain (e.g. acme.com).
3

Verify your domain

Publish the TXT record shown on the connection at _beforequery-verification.<your-domain>, then click Verify domain. DNS can take a few minutes.
4

Test sign-in

From the login page, choose Sign in with SSO and enter an email on your domain. You should be redirected to your IdP and land back in the dashboard signed in. Token signatures are validated against the IdP’s published keys (JWKS).

​
Set up SAML 2.0

1

Create a SAML app in your IdP

Configure the Assertion Consumer Service (ACS) URL:
Then grab the IdP’s SSO URL and its signing certificate (PEM or bare base64) — both are required.
2

Add the connection in BeforeQuery

Add a connection with protocol SAML, your email domain, the SSO URL and the certificate.
3

Verify your domain and test

Publish the TXT record and click Verify domain, then start SSO from the login page with a domain email. The ACS endpoint is public but signature-validated — assertions must be signed by the registered IdP certificate.
OIDC and SAML connections can coexist — sign-in routing picks the right one by domain and protocol.

​
After rollout

  • Provisioning — SSO users are auto-created on first sign-in; no invitations needed. The connection’s default role decides what they join as: member (can create knowledge bases) or user (chat only). Change an individual afterwards from Workspace → Team.
  • Require SSO — once you have signed in through your IdP successfully, turn this on to close password sign-in, password reset, and Google/GitHub sign-in for everyone on that domain. The workspace owner keeps password access, so an IdP outage cannot lock you out.
  • Scope what members can ask — pair SSO with knowledge base permissions: owners can chat with every knowledge base, members only with knowledge bases where they’ve been granted access.
  • Remove a connection — delete it from Workspace → Settings → SSO; affected users fall back to password or social login.

​
Troubleshooting

  • “No SSO connection found” — the email domain doesn’t match any registered connection; check for typos and subdomains.
  • “Domain has not been verified” — finish the TXT record step; sign-in stays closed until it passes.
  • “Address outside this connection’s domain” — the IdP returned an email on another domain. Register that domain as its own connection; one connection authenticates one domain.
  • “Sign-in link has expired” — the flow was started in one browser and finished in another, or took over 10 minutes. Start again from the login page.
  • SAML assertion rejected — the IdP certificate rotated; delete the connection and re-add it with the new certificate.
  • User landed in the wrong workspace — connections are per-workspace; make sure the domain is registered on the intended workspace only.