Skip to main content

Documentation Index

Fetch the complete documentation index at: https://lightdash-mintlify-sso-public-url-validation.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

Lightdash supports multiple SSO providers for secure authentication. This page provides an overview of which providers are available on each plan.

​
Setup for Lightdash Cloud vs self-hosted

If you’re on Lightdash Cloud, you don’t set environment variables yourself. Instead:
  1. Complete the provider-side setup (e.g., create an OAuth app in Okta, Google, Azure AD, etc.) using the setup guides linked below.
  2. Securely share the resulting configuration values (client ID, client secret, issuer URL, etc.) with the Lightdash team.
  3. The Lightdash team will configure SSO on your behalf.
When following the setup guides below, you can skip any steps about setting environment variables — those only apply to self-hosted instances. Focus on the provider-side configuration and note down the values you’ll need to share with Lightdash.

​
SSO providers by plan

ProviderCloud ProEnterpriseSelf-hosted
Google
Okta
Azure AD
OneLogin
Generic OIDC
Self-hosted instances can configure any supported SSO provider by setting environment variables directly. See the self-hosted SSO configuration guide for setup instructions. Lightdash Cloud customers should follow the provider-side setup and share the values with the Lightdash team.

​
URL requirements for organization-managed SSO

When an organization admin saves a per-organization SSO configuration, Lightdash validates that any provider URL it has to fetch resolves to a public https:// address. This protects against server-side request forgery (SSRF) since the URL is requested by the Lightdash backend during issuer discovery. The following fields are validated at save time:
ProviderValidated fieldWhat gets checked
OktaoktaDomainThe domain is used to build https://<oktaDomain> — it must resolve to a public host.
Generic OIDCmetadataDocumentEndpointThe OIDC discovery document URL must use https:// and resolve to a public host.
URLs that point to localhost, loopback addresses, private networks, or other internal/non-routable addresses are rejected with a ParameterError. Azure AD is not affected because its endpoints are templated from the tenant ID.
This check runs only when configuration is saved through the API or admin UI. Existing stored configurations and environment-variable-based self-hosted configurations are not re-validated.
Example error returned when saving an invalid value: 
{
  "error": {
    "name": "ParameterError",
    "message": "OIDC discovery document URL must be a valid public https URL — localhost, private and internal network addresses are not allowed."
  }
}

​
Provider details

​
Google

OAuth 2.0-based authentication using Google accounts. Ideal for organizations using Google Workspace.

​
Okta

OpenID Connect (OIDC) integration with Okta. Supports group synchronization and SCIM provisioning.
  • Included in: Cloud Pro, Enterprise, Self-hosted
  • Features: Group sync, JIT provisioning, custom authorization servers
  • Setup guide: Okta SSO configuration

​
Azure Active Directory

OpenID Connect integration with Microsoft Azure AD. Supports both client secret and private key JWT authentication.
  • Included in: Enterprise, Self-hosted
  • Features: Multiple authentication methods, tenant isolation
  • Setup guide: Azure AD configuration

​
OneLogin

OpenID Connect integration with OneLogin identity platform.

​
Generic OIDC

Connect any OpenID Connect-compliant identity provider (Keycloak, Auth0, PingIdentity, etc.).
  • Included in: Enterprise, Self-hosted
  • Features: Flexible configuration, supports private_key_jwt authentication
  • Setup guide: Generic OIDC configuration

​
Additional authentication options

​
Password authentication

Email/password authentication is available on all plans and enabled by default. Organizations using SSO can disable password authentication to enforce SSO-only login.

​
Warehouse SSO (Enterprise only)

Enterprise customers can also configure SSO for data warehouse connections:
  • Snowflake OAuth - Users authenticate with Snowflake using their corporate identity
  • Databricks OAuth - User-to-Machine (U2M) OAuth flow for Databricks
These create per-user warehouse credentials rather than shared project credentials.