Configuring SSO for Airbyte with Auth0

Overview

Airbyte Enterprise and Cloud editions support single sign-on (SSO) via OpenID Connect (OIDC). Auth0 is a popular identity provider (IdP) that speaks OIDC out-of-the-box, so pairing the two dramatically simplifies user management, strengthens security, and enables enterprise features like multi-factor authentication and centralized access control.

Prerequisites

• Airbyte Cloud workspace or self-hosted Airbyte Enterprise >= 0.40.0
• An Auth0 tenant with admin privileges
• A custom domain (recommended) and SSL certificates
• Ability to restart the Airbyte deployment (Docker, Kubernetes, or Cloud stack)

Why Configure SSO?

Without SSO, each Airbyte user has a standalone username/password. That approach scales poorly and increases risk as organizations grow. SSO centralizes authentication and authorization, letting security teams enforce global policies (MFA, password rotation, conditional access) while giving users one-click access. For regulated industries, SSO is often mandatory for compliance frameworks like SOC 2, ISO 27001, and HIPAA.

Key Concepts

OpenID Connect (OIDC)

OIDC is an identity layer built on top of OAuth 2.0. It defines identity tokens (id_token), discovery endpoints, and standardized user claims. Airbyte’s SSO implementation consumes OIDC tokens and validates them against Auth0’s JSON Web Key Set (JWKS).

Auth0 Application

In Auth0, an Application represents Airbyte. The OIDC client_id, client_secret, and Auth0 domain are surfaced to Airbyte via environment variables or the Airbyte Cloud UI.

Step-by-Step Configuration

1. Create an Application in Auth0

1. Log in to the Auth0 Dashboard → Applications › Applications → Create Application.
2. Name it Airbyte, choose Regular Web Application, and click Create.
3. In Settings:
   • Allowed Callback URLs: https://<AIRBYTE_URL>/auth/callback
   • Allowed Logout URLs: https://<AIRBYTE_URL>/
   • Allowed Web Origins: https://<AIRBYTE_URL>
4. Click Save Changes.
5. Note the Domain, Client ID, and Client Secret.

2. (Optional) Map Additional Claims

Airbyte expects an email address in the email claim. If you need role-based access control (RBAC), add a groups or roles claim using an Auth0 Rule or Action so Airbyte can authorize on group membership.

3. Gather OIDC Discovery Values

Open https://<AUTH0_DOMAIN>/.well-known/openid-configuration to copy:

• issuer
• jwks_uri
• authorization_endpoint
• token_endpoint

4. Configure Airbyte

For self-hosted Docker Compose, edit .env:

# Enable OIDC
AIRBYTE_AUTHENTICATION_METHOD=OIDC
AIRBYTE_OIDC_ISSUER=<issuer>
AIRBYTE_OIDC_JWKS_ENDPOINT=<jwks_uri>
AIRBYTE_OIDC_CLIENT_ID=<client_id>
AIRBYTE_OIDC_CLIENT_SECRET=<client_secret>
AIRBYTE_OIDC_AUTHORIZATION_ENDPOINT=<authorization_endpoint>
AIRBYTE_OIDC_TOKEN_ENDPOINT=<token_endpoint>
AIRBYTE_OIDC_SCOPES=openid email profile
AIRBYTE_OIDC_ALLOWED_EMAIL_DOMAINS=mycompany.com


For Airbyte Cloud, navigate to Settings › SSO and paste the same values.

5. Restart Airbyte

docker compose down && docker compose up -d (or redeploy your Kubernetes/Cloud stack).

6. Test the Flow

1. Visit https://<AIRBYTE_URL>. You should be redirected to Auth0.
2. Log in with an Auth0 user whose email domain matches AIRBYTE_OIDC_ALLOWED_EMAIL_DOMAINS.
3. After consent, you are redirected back to Airbyte and automatically signed in.

7. Enforce MFA & Compliance (Optional)

Leverage Auth0’s Security › Multi-factor Auth to require MFA. Pair with conditional access policies (IP allowlists, device posture) for hardened production environments.

Best Practices

• Use a custom Auth0 domain to avoid *.auth0.com cookies being blocked by browser security settings.
• Rotate signing keys periodically; Airbyte fetches the JWKS automatically.
• Restrict allowed email domains and set email_verified to true in Auth0 to block spoofed users.
• Version-control Docker Compose or Kubernetes manifests so SSO settings are auditable.
• Monitor Auth0 logs and federate them to SIEM tooling for incident response.

Galaxy Relevance

While Galaxy is a SQL editor and not directly tied to Airbyte’s SSO, teams that orchestrate data pipelines with Airbyte often analyze those pipelines’ outputs in Galaxy. Ensuring Airbyte is securely accessible through SSO complements Galaxy’s own access-control model, allowing data engineers to move seamlessly between extraction (Airbyte) and analysis (Galaxy) with a single identity provider.

Common Pitfalls & Fixes

Email Domain Mismatch

If users see “Access Denied,” verify that AIRBYTE_OIDC_ALLOWED_EMAIL_DOMAINS includes the user’s domain and that the email claim is present and verified.

Incorrect Audience or Issuer

Auth0’s application audience must equal AIRBYTE_OIDC_CLIENT_ID. A typo leads to “Invalid token signature.” Copy values directly from the Auth0 dashboard and restart Airbyte.

Expired Client Secret

Auth0 rotates secrets if you click “Regenerate.” Update the corresponding Airbyte env var immediately to avoid login failures.

Next Steps

• Integrate Airbyte login events with your SOC2 evidence collection.
• Automate user provisioning via SCIM or Auth0 Management API.
• Evaluate Just-In-Time access roles in Airbyte to enforce least privilege.