Revert SSO Epic

[midigofrank]

Description

This PR reverts the Single Sign-On epic (#4751) so it isn't part of the incoming release, giving it time for a proper security review before it ships.

Why this isn't a plain git revert

SSO landed as one squashed commit (8038271d03), and then the v2.17.0 release was merged on top of it (48874fb308). Both branches had independently rewritten the same auth code, so that merge picked SSO's architecture for the auth cluster and then ported v2.17.0's OIDC hardening onto it. Reverting the SSO commit directly would conflict in exactly the files the merge reshaped, and resolving those by hand risks silently reinstating pre-v2.17.0 (unhardened) auth code.

Instead, the revert target for every auth file is the v2.17.0 tag, which holds a complete, SSO-free, already-hardened version of the whole auth cluster. 43 of the 51 SSO files have no commits other than the SSO commit and the merge since that tag, so restoring them from v2.17.0 is the revert, and it brings the security release back verbatim rather than re-deriving it. Only 8 files needed hand edits.

Kept deliberately, rather than reverted

• The dead-code removal of auth_providers/{common,google,salesforce,oauth_behaviour}.ex and Config.oauth_provider/1. That was an independent cleanup (refactor: remove unused modules #4825) that happened to be bundled into the SSO PR; nothing in lib/ or test/ references any of it, so restoring it would re-add dead code.
• The credential_live_test.exs hunk that replaced Common.TokenBody.new/1 with a plain map match, since Common stays deleted.
• DEPLOYMENT.md's "OAuth credential connections" section. The SSO PR didn't just add SSO docs — it replaced the old "Google Oauth2" / "Salesforce Oauth2" sections with a new, accurate section explaining that GOOGLE_CLIENT_ID and SALESFORCE_CLIENT_ID are no longer read and that OAuth clients are now registered in the UI. That replacement is correct and unrelated to SSO, so it stays; only its cross-reference to the SSO section is removed. Restoring the originals would have re-published setup instructions for environment variables nothing reads.

Migrations

All three SSO migrations are deleted outright, with no down-migration. They only ever ran on local and CI databases — there is no deployed schema to roll back. A fresh setup now produces the pre-SSO schema: no user_identities table, and users.hashed_password back to NOT NULL.

Deleting the files (rather than reversing them) also means they'll re-run cleanly at their original timestamps when SSO re-lands.

⚠️ If you have run this branch locally, read this

Your local database still has the SSO schema, and any account you created via SSO has no password — after this revert there is no password-less login path, so that account is locked out.

Simplest fix:

mix ecto.reset                       # dev
MIX_ENV=test mix ecto.reset          # test

To keep your existing data instead, in psql lightning_dev:

-- 1. Deal with password-less accounts FIRST (see below to keep one).
DELETE FROM users WHERE hashed_password IS NULL;

-- 2. Drop the SSO schema and forget its migrations.
DROP TABLE IF EXISTS user_identities;
DELETE FROM schema_migrations
WHERE version IN (20260515133932, 20260515133933, 20260616180455);

-- 3. Restore the original constraint.
ALTER TABLE users ALTER COLUMN hashed_password SET NOT NULL;

To keep a password-less account rather than delete it, give it a password before step 1: use "Forgot your password?" on /users/log_in and open the reset email at http://localhost:4000/dev/mailbox. Steps 2–3 will then succeed with no deletions.

Validation steps

1. Confirm the previous release survived — git diff v2.17.0 HEAD -- lib/lightning/auth_providers lib/lightning_web/controllers/oidc_controller.ex lib/lightning/accounts.ex lib/lightning/accounts/user.ex should show nothing but the four deliberately-deleted dead modules listed above.
2. Confirm no SSO residue: git grep -In "user_identities\|hashed_password: nil\|SSO_GITHUB\|SSO_GOOGLE\|UserIdentity\|link_user_identity" -- lib test priv config returns nothing.
3. mix ecto.reset then mix compile --force --warnings-as-errors — should be clean, and the resulting schema should have no user_identities table.
4. Run the auth surface: mix test test/lightning/accounts_test.exs test/lightning/auth_providers/ test/lightning_web/controllers/oidc_controller_test.exs test/lightning_web/controllers/user_session_controller_test.exs test/lightning_web/live/profile_live_test.exs test/lightning_web/live/reauthenticate_live_test.exs test/lightning_web/live/project_live_test.exs
5. Smoke test in the browser: /users/log_in shows no SSO buttons and password login works (including the "disabled" and "scheduled for deletion" messages); /authenticate/github and /authenticate/signup/confirm both 404 without crashing; /profile renders with no "Linked accounts" section and password change works; revealing a webhook auth method secret still prompts for password/2FA.
6. If you have an admin-configured generic OIDC provider reachable, log in through it once — that's the flow v2.17.0 hardened, and it's the one that must still work.

Additional notes for the reviewer

Two SSO dependencies that greps didn't catch — both were found by the test suite, so they're worth knowing about if you're reviewing the completeness of the revert:

1. test/lightning/auth_providers/auth_providers_test.exs asserted Handler.authorize_url/2 (SSO's params-based arity) against v2.17.0's authorize_url/3. It is not part of the SSO commit — the merge adapted it. Enumerating the reverted commit's file list isn't sufficient; the correct scan looks repo-wide for files whose only commits since the v2.17.0 tag are those two SHAs.
2. Two tests in test/lightning_web/live/project_live_test.exs (describe "webhook-security") exercise the password-less webhook-secret-reveal path. They contain no SSO identifier at all — they set up insert(:user, hashed_password: nil, ...). hashed_password: nil turned out to be the real fingerprint of SSO-dependent test setup. Both were removed. (These tests originally lived in trigger_test.exs; the legacy-editor sunset feat: sunsetting legacy editor #4908 moved them into project_live_test.exs.)

Test results: the auth surface is 262 tests / 0 failures, adjacent suites (credential, user, version_control, registration, auth_providers_live) 164 / 0. The full suite is 5188 tests, 1 failure, and that one failure is an environment artefact, not a regression: test/integration/web_and_worker_test.exs:119 asserts the reported Node version starts with 24.18, and I'd been running with a stale ASDF_NODEJS_VERSION=24.15.0 override. It passes with the repo default from .tool-versions (nodejs 24.18.0). mix format, mix compile --warnings-as-errors, mix credo --strict --all and mix sobelow are all clean.

Bringing it back. git revert of this PR's revert commit on a branch off main restores everything — the code is never lost, so nothing needs parking. Three things make it more than a revert, though: the three migrations come back at their original timestamps, which by then will be older than migrations already applied in production (Ecto runs them anyway but warns, and a later mix ecto.rollback would then revert the wrong migration — so re-stamp them); the security review has to actually happen; and the revert restores the merged hybrid (SSO's env-provider userinfo path running alongside v2.17.0's id_token-verifying AuthConfig path), which is the architectural split worth collapsing deliberately rather than restoring as-is. Full re-land procedure is written up alongside the plan in the shared context folder.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our
Responsible AI Policy

Pre-submission checklist

• I have performed an AI review of my code (we recommend using /review
  with Claude Code)
• I have implemented and tested all related authorization policies.
  (e.g., :owner, :admin, :editor, :viewer) — n/a for a revert; this
  restores v2.17.0's authorization behaviour verbatim, covered by its own tests
• I have updated the changelog.
• I have ticked a box in "AI usage" in this PR

[github-actions]

Based on my review, this PR is a revert of the SSO epic. It removes SSO-related routes, controllers, LiveComponents, migrations, user identities, and helper functions. There are no additions of new project-scoped queries, new authorization-gated actions, or new config-resource writes. All three checks are N/A.

Security Review ✅

• S0 (project scoping): N/A — the changes touch user authentication, profile, and OIDC controllers only; no new queries or web-layer entrypoints for project-scoped resources (workflows, runs, dataclips, etc.) are added.
• S1 (authorization): N/A — this is a revert; no new create/read/update/delete actions are introduced. The webhook-auth reauthentication in webhook_auth_method_form_component.ex drops the SSO-only bypass, tightening (not loosening) the gate.
• S2 (audit trail): N/A — no new writes to workflows, credentials, project settings, webhook auth methods, OAuth clients, or version-control config; the diff removes SSO user-identity CRUD rather than adding any auditable config-resource operations.

[codecov]

Codecov Report

❌ Patch coverage is 93.58974% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.7%. Comparing base (ed4f5e3) to head (764b94a).

Files with missing lines	Patch %	Lines
lib/lightning_web/controllers/oidc_controller.ex	95.6%	2 Missing ⚠️
.../lightning_web/live/profile_live/form_component.ex	71.4%	2 Missing ⚠️
lib/lightning/auth_providers/cache_warmer.ex	66.7%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #5032     +/-   ##
=======================================
+ Coverage   90.5%   90.7%   +0.2%     
=======================================
  Files        425     420      -5     
  Lines      20233   19953    -280     
=======================================
- Hits       18308   18095    -213     
+ Misses      1925    1858     -67     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.