Configure the external OIDC auth provider via env vars (align with GitHub/Google SSO)
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 inlib/lightning/config/bootstrap.ex:506-530- Handlers built by
GithubHandler.build/0/GoogleHandler.build/0(readingConfig.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):
AuthConfigschema ->auth_providerstable (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
CacheWarmerviaAuthProviders.get_existing/0; served throughget_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/0usesRepo.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 inbootstrap.ex - A
Config.oidc_oauth/1accessor + anOidcHandler.build/0analogous to the GitHub/Google handlers - Redirect URI derived from the configured name via
sso_redirect_uri/4 - Register it in
CacheWarmeralongside 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 ofCacheWarmerAuthConfigschema +auth_providerstable (drop migration, or deprecate first)- Login-button logic in
user_session_controller.ex setup_utils.ex(referenced in teardown) and any seedsDEPLOYMENT.mdSSO section
Open questions / decisions
- Discovery URL vs. explicit endpoints? Either provide a single
SSO_OIDC_DISCOVERY_URL(fetched into aWellKnownat boot - one var, always in sync with the IdP, but requires the.well-knowndoc 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 constructWellKnown, 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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