Skip to content
datarelix.ai docs

Authentication

Authentication

datarelix.ai has three layers of auth:

  1. API key — for server-to-server access to the orchestrator.
  2. User SSO — for browser sign-in (Google, Microsoft Entra, GitHub).
  3. Per-user database auth — On-Behalf-Of for Azure SQL/Synapse, Databricks, Kusto.

API key

Every API request requires an X-API-Key header. Workspace API keys are provisioned by datarelix.ai — contact us or ask your workspace admin to issue one. Keep it secret; treat it like a password.

Terminal window
curl -H "X-API-Key: $DATARELIX_API_KEY" https://app.datarelix.ai/api/v1/connections

API keys are checked first. Without a valid key, every request returns 401.

Browser SSO

Sign in to the app with any of three identity providers — no setup required:

  • Google Workspace
  • Microsoft Entra (Azure AD) — single- or multi-tenant
  • GitHub

Enterprise plans can add custom SSO mapping and SCIM provisioning — contact us.

Sign-in produces a session JWT stored in an HttpOnly cookie. The browser also sends X-API-Key for server-side ID; both are accepted.

When the orchestrator sees both an API key and a session JWT, the session JWT’s sub is used as the user identity (because that’s our internal ID; the API key is shared infrastructure).

Google + BigQuery auto-connect

If the same Google OAuth app is used for SSO and BigQuery, the SSO flow requests the bigquery.readonly scope alongside openid profile email. The refresh token is stored on the user record and auto-fills BigQuery OAuth connections — no second consent screen.

This only works when the BigQuery OAuth client and the SSO client are the same Google project. With separate apps, the user gets the standard BigQuery consent popup the first time.

On-Behalf-Of (OBO) for databases

For Azure SQL/Synapse, Databricks, and Kusto, datarelix.ai can use the user’s signed-in identity to authenticate the database connection — instead of running everything as a shared service principal.

Requirements:

  • Browser sign-in via Microsoft Entra (or another federated provider Databricks understands).
  • An Entra app registration with delegated permissions to the target database (Azure SQL, ADX, or Databricks).

When OBO is enabled on a connection, the orchestrator exchanges the user’s access token for a database token using the OBO grant. The connection inherits the user’s permissions exactly — no shared credentials.

For the customer-side Entra app registration and grants, see the per-dialect setup guides: Azure SQL / Synapse, Kusto, and Databricks.

Logout

POST /auth/logout clears the session cookie and revokes refresh tokens. Session refresh middleware skips this endpoint and /auth/refresh to avoid rotating tokens for users on the way out.