Feature request: OIDC SSO support (Okta, Azure AD, Google, etc.)

[antoniocali]

Summary

olake-ui currently supports only local username/password auth with server-side cookie sessions (server/internal/handlers/auth.go — Login, Signup, CheckAuth). For enterprise deployments — typically the same shape as the Fusion + Helm setups documented in olake-helm — this is a real gap: there's no way to plug the app into an existing identity provider (Okta, Azure AD, Google Workspace, Auth0, Keycloak, etc.) for centralized identity, MFA, group-based access, or offboarding.

I'd like to request OIDC (OpenID Connect) support as the integration shape. OIDC is the lowest-common-denominator — every IdP listed above can expose itself as a generic OIDC application, so a single implementation covers them all. SAML would also unblock some enterprise environments, but it's heavier to implement and most teams that need SAML can also do OIDC; suggest starting with OIDC and treating SAML as a follow-up only if asked.

Proposed shape (sketch, open to alternatives)

Server-side:

• New config block (env / app.yaml), all optional and disabled by default:

  • OIDC_ENABLED (bool, default false)
  • OIDC_ISSUER_URL (e.g. https://example.okta.com/oauth2/default)
  • OIDC_CLIENT_ID, OIDC_CLIENT_SECRET
  • OIDC_REDIRECT_URL (e.g. https://olake.example.com/auth/oidc/callback)
  • OIDC_SCOPES (default openid profile email)
  • OIDC_USERNAME_CLAIM (default preferred_username, fallback email)
  • OIDC_AUTO_PROVISION (bool, default true) — JIT-create local user on first successful login

• New handlers (server/internal/handlers/auth.go or a new oidc.go):

  • GET /auth/oidc/start — redirect to the IdP authorize endpoint, with state+PKCE in the session.
  • GET /auth/oidc/callback — exchange code → ID token → verify → resolve/create local user → call the existing h.sessions.SetUserSession(c, user.ID).

  Reusing the existing session/cookie layer means everything downstream (the CheckAuth middleware, every existing endpoint) keeps working with zero changes.

• A small DB migration adding nullable oidc_subject and oidc_issuer columns to the user table so we can identify federated users without colliding with local ones.

UI side:

• Conditional "Sign in with SSO" button on the login page when the backend exposes oidc_enabled: true via an existing config endpoint (or via a new /auth/providers endpoint).
• No other UI changes — the post-callback redirect lands on the existing app shell with a valid session.

Smaller alternative

For teams that only need to satisfy a "must be behind SSO" policy and don't care about user-level federation, a thinner change is enough: accept an upstream identity header (X-Auth-Request-Email or similar, ~oauth2-proxy convention) and mint a session if the configured trusted-proxy CIDR matches. ~50 lines of Go. Useful as a stopgap but doesn't replace proper OIDC for groups/claims/auto-provisioning.

Helm

The chart already passes olakeUI.env through, so the new OIDC_* vars need no template change. A README section similar to the existing "Private Container Registry" would cover discoverability.

Context

• Background: I run OLake on EKS as the Fusion + Polaris optimizer layer. The local-user model is the only thing preventing me from putting this in front of the wider data team behind our existing Okta tenant — every other internal tool is SSO-enforced for policy reasons.
• Happy to PR this if there's interest. Suggest landing it behind OIDC_ENABLED=false so existing deployments are untouched.

[merlynm20]

@antoniocali Thank you for raising the SSO feature request.
At the moment, SSO is planned as part of the managed SaaS offering of Olake and is not currently in scope for the open-source version. Our focus for OSS remains on providing the core data ingestion capabilities, while enterprise features such as SSO will be available through the managed platform.
We appreciate the feedback and will keep the community updated as the managed offering evolves.