OpenFn / OpenFn/lightning

Configure the external OIDC auth provider via env vars (align with GitHub/Google SSO)

Open
#4,904 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Elixir
Stars
296
Forks
86
Avg merge
1d 13h
Merged PRs (30d)
50

Description

Background

This PR (#4621) introduced SSO sign-in for GitHub and Google, configured entirely through environment variables. The pre-existing external/generic OIDC provider is still configured the old way — a database row (AuthConfig) managed through an admin UI. We now have two parallel mechanisms for the same concept. This issue proposes migrating the external provider to env-var configuration so all SSO providers are configured consistently, and retiring the DB/admin-UI path.

Current state

GitHub/Google (env-based):

  • SSO_GITHUB_* / SSO_GOOGLE_* read in lib/lightning/config/bootstrap.ex:506-530
  • Handlers built by GithubHandler.build/0 / GoogleHandler.build/0 (reading Config.github_oauth/1 / google_oauth/1)
  • Registered into the handler cache by AuthProviders.CacheWarmer
  • Redirect URI derived automatically via sso_redirect_uri/4 (bootstrap.ex:1054)

External provider (DB-based):

  • AuthConfig schema -> auth_providers table (lib/lightning/auth_providers/auth_config.ex)
  • Configured via admin UI: /settings/authentication[/new] (router.ex:232-233), AuthProvidersLive.Index, AuthConfigForm, live/auth_providers/form_component.ex
  • Loaded by CacheWarmer via AuthProviders.get_existing/0; served through get_handler/1 -> find_and_build/1 -> Handler.from_model/1
  • Surfaced on the login page via get_existing/0 (user_session_controller.ex:123)
  • Limited to one provider row (get_existing/0 uses Repo.one)

Goal

Configure the external OIDC provider through environment variables (mirroring GitHub/Google) and remove the DB-backed configuration + admin UI.

Proposed shape (starting point - open to discussion)

  • New vars, e.g. SSO_OIDC_NAME, SSO_OIDC_CLIENT_ID, SSO_OIDC_CLIENT_SECRET, plus either a discovery URL or explicit endpoints (see open questions), read in bootstrap.ex
  • A Config.oidc_oauth/1 accessor + an OidcHandler.build/0 analogous to the GitHub/Google handlers
  • Redirect URI derived from the configured name via sso_redirect_uri/4
  • Register it in CacheWarmer alongside the others

Touchpoints to migrate / remove

  • Admin UI: router.ex:232-233, AuthProvidersLive.Index, AuthConfigForm, live/auth_providers/form_component.ex, auth_providers_live_test.exs
  • auth_providers.ex: get_existing/{0,1}, create/1, update/2, delete!/1, the DB branch of CacheWarmer
  • AuthConfig schema + auth_providers table (drop migration, or deprecate first)
  • Login-button logic in user_session_controller.ex
  • setup_utils.ex (referenced in teardown) and any seeds
  • DEPLOYMENT.md SSO section

Open questions / decisions

  • Discovery URL vs. explicit endpoints? Either provide a single SSO_OIDC_DISCOVERY_URL (fetched into a WellKnown at boot - one var, always in sync with the IdP, but requires the .well-known doc to be reachable), or have operators set the three endpoints directly - SSO_OIDC_AUTHORIZATION_ENDPOINT, SSO_OIDC_TOKEN_ENDPOINT, SSO_OIDC_USERINFO_ENDPOINT (no network fetch, mirrors how the GitHub/Google handlers already construct WellKnown, but more vars and they can drift from the IdP).
  • Fixed provider name vs. configurable (SSO_OIDC_NAME)? The name drives the callback path /authenticate/<name>/callback, so changing it requires re-registering the redirect URI at the IdP.
  • Support multiple external providers, or keep the current single-provider limit?
  • Back-compat: existing self-hosted installs with a DB-configured provider would need to move their config to env vars on upgrade - do we drop the table immediately or deprecate over a release?

Related: #4621

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with lib/lightning/config/bootstrap.ex:506-530 and the existing GitHub/Google handler and CacheWarmer paths, then trace the external provider touchpoints listed in auth_providers.ex and user_session_controller.ex. Resolve the discovery-versus-endpoints, provider name, multiplicity, and migration decisions before implementation. Done means the external OIDC provider uses environment configuration consistently, the DB/admin-UI path and related tests or setup are handled, and DEPLOYMENT.md is updated.

Written by the indexing model from the issue text.

Assessment

Tech stack
elixir
Domain
authentication, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.