https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT>, how to configure oidc login with g...
# replication-ask-ai
y
@kapa.ai, how to configure oidc login with google auth in latest version of airbyte ?
k
Airbyte’s docs describe how to enable OIDC SSO in general, but they do not provide a Google-specific OIDC example. They only give concrete setup guides for Okta and Microsoft Entra ID. [[SSO overview](https://docs.airbyte.com/platform/access-management/sso)] Because of that, I can only outline the Airbyte side of the configuration and where it plugs into your IdP; I can’t give step‑by‑step Google Cloud Console instructions from these sources. ### 1. Requirements and scope - OIDC SSO is available for Airbyte Cloud Teams and Self‑Managed Enterprise editions. [[March 2024 release](https://docs.airbyte.com/release_notes/march_2024); [SSO overview](https://docs.airbyte.com/platform/access-management/sso)] - For self‑managed, you configure it via 
values.yaml
in the Helm chart (V1 or V2). [[Helm V2 upgrade](https://docs.airbyte.com/platform/enterprise-setup/chart-v2-enterprise#update-your-valuesyaml-file)] ### 2. Configure OIDC SSO in 
values.yaml
(self‑managed) For Helm chart V2 with standard OIDC, your 
values.yaml
should include:
Copy code
yaml global:   edition: enterprise   airbyteUrl: "<https://airbyte.your-company.com>"    auth:     # Admin user configuration     instanceAdmin:       firstName: "Admin"       lastName: "User"       emailSecretKey: "instance-admin-email"       passwordSecretKey: "instance-admin-password"      # SSO Identity Provider configuration     identityProvider:       secretName: "airbyte-config-secrets"  # Kubernetes secret containing OIDC client credentials       type: "oidc"       oidc:         # OIDC application domain (your IdP / auth domain)         domain: "your-google-oidc-domain"         # OIDC application name (used in redirect URL and UI label)         appName: "airbyte"         # Keys inside the Kubernetes secret where client id/secret are stored         clientIdSecretKey: "client-id"         clientSecretSecretKey: "client-secret"
[[Helm V2 upgrade](https://docs.airbyte.com/platform/enterprise-setup/chart-v2-enterprise#update-your-valuesyaml-file); [Implementation guide](https://docs.airbyte.com/platform/enterprise-setup/implementation-guide#step-2-configure-your-deployment)] Key points: - 
global.edition: enterprise
is required. [[Implementation guide](https://docs.airbyte.com/platform/enterprise-setup/implementation-guide#step-2-configure-your-deployment)] - 
airbyteUrl
must be the public URL that users will access and that you configure as a redirect URL in your IdP. [[Implementation guide](https://docs.airbyte.com/platform/enterprise-setup/implementation-guide#step-2-configure-your-deployment)] - 
identityProvider.secretName
points to a Kubernetes Secret that must contain at least: - 
client-id
- 
client-secret
(or whatever keys you reference in 
clientIdSecretKey
/ 
clientSecretSecretKey
). [[Implementation guide](https://docs.airbyte.com/platform/1.8/enterprise-setup/implementation-guide#step-2-configure-your-deployment)] If you instead use generic OIDC (more explicit endpoints/claims), the structure is:
Copy code
yaml global:   auth:     instanceAdmin:       firstName: "Admin"       lastName: "User"       emailSecretKey: "instance-admin-email"       passwordSecretKey: "instance-admin-password"      identityProvider:       secretName: "airbyte-config-secrets"       type: "generic-oidc"       genericOidc:         clientId: "your-google-client-id"         audience: "your-audience"         extraScopes: "openid email profile"         issuer: "<https://your-google-issuer>"         endpoints:           authorizationServerEndpoint: "<https://your-google-auth-endpoint>"           jwksEndpoint: "<https://your-google-jwks-endpoint>"         fields:           subject: sub           email: email           name: name           issuer: iss
[[Helm V2 upgrade](https://docs.airbyte.com/platform/enterprise-setup/chart-v2-enterprise#update-your-valuesyaml-file)] ### 3. IdP (Google) side – what Airbyte expects The docs only describe this generically, not for Google specifically: - You must create an OIDC application in your IdP and collect: - Client ID - Client secret - Issuer / domain - Authorization and JWKS endpoints (for generic OIDC) [[Helm V2 upgrade](https://docs.airbyte.com/platform/enterprise-setup/chart-v2-enterprise#update-your-valuesyaml-file)] - Configure redirect/callback URL(s) in the IdP to match your 
airbyteUrl
and the OIDC callback path used by Airbyte (the exact path is not documented in the provided sources, so I cannot state it confidently). - For Cloud, users log in via Continue with SSO and a company identifier; for self‑managed, users go directly to your Airbyte URL and are redirected to the IdP. [[SSO overview](https://docs.airbyte.com/platform/access-management/sso)] Because the knowledge sources do not include a Google‑specific OIDC guide (only Okta and Entra ID), I cannot provide the exact Google Cloud Console screens or redirect URL format. You’ll need to follow Google’s OIDC app setup docs and map the resulting values into the 
values.yaml
fields above. If you share which deployment you’re using (Cloud vs self‑managed, Helm chart version), I can narrow the exact 
values.yaml
snippet you should use based only on the docs.
y
Hi @kapa.ai, are you saying that the integration is not available on community edition ?
k
A message from kapa.ai
Yes. Based on the docs, OIDC/SSO login is not available on the Self‑Managed Community (open‑source) edition. SSO via OpenID Connect is listed as available only for: - Airbyte Cloud (with Teams / higher tiers) - Self‑Managed Enterprise (licensed) [[Self‑Managed Enterprise 1.0](https://docs.airbyte.com/release_notes/v-1.0#self-managed-enterprise); [SSO access-management](https://docs.airbyte.com/platform/access-management/sso)] In the SSO docs, the feature matrix explicitly marks SSO as Not available for Core/Standard/Plus (which correspond to non‑enterprise/community tiers) and Available for Pro, Enterprise Flex, and Self‑Managed Enterprise. [[SSO access-management](https://docs.airbyte.com/platform/access-management/sso)] So: OIDC/SSO login is supported for Enterprise/Pro/Cloud Teams, but not for the Community edition.
y
@kapa.ai, form which version did airbyte require the instance to be enterprise to use sso ?
k
A message from kapa.ai
The docs don’t state a single “cutover” version explicitly, but they do show the requirement consistently across versions we have: - In 1.6 and 1.7, SSO is marked as Available only for “Pro”, “Enterprise Flex”, and Self‑Managed Enterprise, and Not available for the lower tiers (which correspond to Community). [[SSO 1.6](https://docs.airbyte.com/platform/1.6/access-management/sso); [SSO 1.7](https://docs.airbyte.com/platform/1.7/access-management/sso)] - In 1.8 and “Next” docs, SSO via OIDC is likewise only available for Pro/Enterprise Flex/Self‑Managed Enterprise, not for Core/Standard/Plus. [[SSO 1.8](https://docs.airbyte.com/platform/1.8/access-management/sso); [SSO Next](https://docs.airbyte.com/platform/access-management/sso)] - The 1.0 Self‑Managed Enterprise release notes already describe SSO (Okta/OIDC) as part of the Enterprise feature set. [[1.0 Self‑Managed Enterprise](https://docs.airbyte.com/release_notes/v-1.0#self-managed-enterprise)] From these sources, SSO has been treated as an Enterprise‑level feature since at least the 1.0 Enterprise release, and all documented 1.x versions (1.6, 1.7, 1.8, Next) require an Enterprise/Pro tier (or Cloud Teams) rather than Community for SSO. The docs do not show any 1.x version where Community could use SSO.
y
@kapa.ai Is it configurable on open source edition using authProxy ?
k
A message from kapa.ai
The knowledge sources only describe SSO/OIDC as a built‑in feature for Airbyte Cloud and Self‑Managed Enterprise, and explicitly mark it as not available for the lower / community tiers. [[SSO overview](https://docs.airbyte.com/platform/access-management/sso)] They also only document two ways to enable SSO: - Cloud UI configuration (with Okta / Entra ID) [[Okta Cloud](https://docs.airbyte.com/platform/access-management/sso-providers/okta#cloud-with-okta-oidc)] - Self‑Managed Enterprise via 
values.yaml
and the 
global.auth.identityProvider
settings in the Helm chart [[Implementation guide](https://docs.airbyte.com/platform/enterprise-setup/implementation-guide#step-2-configure-your-deployment)] There is no mention in these docs of: - An 
authProxy
option - Using an external auth proxy to front the open‑source / community edition to provide SSO Because of that, I can’t confirm from the official documentation that configuring SSO on the open‑source edition via 
authProxy
is supported, nor provide a documented setup for it. The docs only describe SSO as an Enterprise/Pro/Cloud feature, not as something configurable on the community edition. [[SSO 1.8](https://docs.airbyte.com/platform/1.8/access-management/sso); [SSO Next](https://docs.airbyte.com/platform/next/access-management/sso)] So, based on the available sources: there is no documented, supported way to enable SSO on the open‑source edition using 
authProxy
.
y
@kapa.ai, how to configure username and password for airbyte user then ?
k
A message from kapa.ai
On the open‑source / Community edition, you use Airbyte’s built‑in basic authentication (email + password). How you configure it depends on how you deployed Airbyte. --- ## If you installed with 
abctl
(local / Kubernetes via abctl) 1. Get the current credentials
Copy code
bash abctl local credentials
This prints the login email, password, client-id, and client-secret. [[OSS quickstart](https://docs.airbyte.com/platform/using-airbyte/getting-started/oss-quickstart#part-4-set-up-authentication)] 2. Change the password
Copy code
bash abctl local credentials --password YourStrongPasswordExample
This restarts the Airbyte server; then you log in with the same email and the new password. [[OSS quickstart](https://docs.airbyte.com/platform/using-airbyte/getting-started/oss-quickstart#part-4-set-up-authentication)] --- ## If you deployed with Helm directly (your own Kubernetes cluster) 1. Read the auth secret
Copy code
bash kubectl get secret airbyte-auth-secrets -n <YOUR_NAMESPACE> -o yaml
You’ll see base64‑encoded values like:
Copy code
yaml data:   instance-admin-client-id: ...   instance-admin-client-secret: ...   instance-admin-password: ...
[[Auth docs](https://docs.airbyte.com/platform/deploying-airbyte/integrations/authentication)] 2. Decode the password
Copy code
bash echo 'BASE64_PASSWORD_HERE' | base64 -d
Use that decoded value as the password. [[Auth docs](https://docs.airbyte.com/platform/deploying-airbyte/integrations/authentication)] 3. Optionally set your own password via a Secret Create `secret.yaml`:
Copy code
yaml apiVersion: v1 kind: Secret metadata:   name: airbyte-auth-secrets type: Opaque stringData:   instance-admin-password: YourStrongPasswordExample    # Optional: override API client credentials   #instance-admin-client-id: my-client-id   #instance-admin-client-secret: my-client-secret
Apply it:
Copy code
bash kubectl apply -f secret.yaml -n <YOUR_NAMESPACE>
You may need to restart the 
airbyte-server
pod. [[Auth docs](https://docs.airbyte.com/platform/deploying-airbyte/integrations/authentication)] --- ## Older Docker/.env‑based installs Some older tutorials use basic auth via environment variables:
Copy code
env BASIC_AUTH_USERNAME=airbyte BASIC_AUTH_PASSWORD=password
You’d set these in the 
.env
file used by Docker Compose, then restart the stack. [[Airflow tutorial](https://airbyte.com/tutorials/how-to-use-airflow-and-airbyte-together)] --- If you tell me how you installed Airbyte (abctl vs Helm vs Docker), I can point you to the exact command/file you should edit.
y
@kapa.ai, can I configure during the installation what username, password to use on values.yaml on helm chart 2 ?
k
A message from kapa.ai
Yes, you can control the initial username/password when using Helm chart v2, but it’s done via Kubernetes Secrets, not by putting the raw values directly into 
values.yaml
. There are two relevant pieces: --- ### 1. Built‑in basic auth (Community / all editions) For the default email/password login, Airbyte reads from the 
airbyte-auth-secrets
Secret. You can create it before installing or upgrading the chart:
Copy code
yaml apiVersion: v1 kind: Secret metadata:   name: airbyte-auth-secrets type: Opaque stringData:   instance-admin-password: YOUR_PASSWORD_HERE    # Optional: override API client credentials   #instance-admin-client-id: my-client-id   #instance-admin-client-secret: my-client-secret
Apply it:
Copy code
bash kubectl apply -f secret.yaml -n <YOUR_NAMESPACE>
Airbyte will then use this password for the admin user. [[Auth integration](https://docs.airbyte.com/platform/deploying-airbyte/integrations/authentication)] You do not specify the password directly in `values.yaml`; you just ensure this Secret exists. --- ### 2. Enterprise SSO bootstrap user (Helm v2, Enterprise only) For Self‑Managed Enterprise with Helm v2, 
values.yaml
lets you point to Secrets that hold the initial admin email and password:
Copy code
yaml global:   auth:     instanceAdmin:       firstName: "Admin"       lastName: "User"       emailSecretKey: "instance-admin-email"      # key inside a Secret       passwordSecretKey: "instance-admin-password" # key inside a Secret
These keys must exist in a Kubernetes Secret you create beforehand (commonly 
airbyte-config-secrets
). [[Enterprise implementation](https://docs.airbyte.com/platform/enterprise-setup/implementation-guide#step-2-configure-your-deployment); [Helm v2 enterprise](https://docs.airbyte.com/platform/enterprise-setup/chart-v2-enterprise#update-your-valuesyaml-file)] Again, the actual email/password values live in the Secret; 
values.yaml
only references the keys. --- So: you can decide the username/password at install time, but you do it by creating the appropriate Secret(s) and, for Enterprise, wiring them via 
global.auth.instanceAdmin
in 
values.yaml
, not by putting the cleartext credentials directly into 
values.yaml
.
5 Views
Open in Slack
PreviousNext
Powered by