[authn] Enabling Google OAuth SSO for a domain permanently locks out the org's first/root admin account

Enabling SSO for a domain permanently locks out the org's first/root admin account

What happened

If the org's first admin account is registered with an email on domain example.com, and SSO is later enabled for example.com, that account becomes unreachable by any authentication path:

• It cannot sign in via Google OAuth — SSO sign-in is rejected for this account.
• It cannot sign in with its password — the login form never offers a password field. It collects the email, runs the domain precheck, sees the domain is SSO-enabled, and redirects to the SSO flow before any credential entry.

The result is a dead end: the only account with org-owner rights can no longer authenticate, and because it is the root account there is no second admin to recover it from.

Steps to reproduce

1. Fresh self-hosted install. Complete setup, registering the first (root/owner) account as [email protected].
2. Sign in as that account.
3. Enable Google OAuth SSO for the domain example.com.
4. Sign out.
5. Attempt to sign in as [email protected].

Expected

One of:

• the root account can authenticate via SSO like any other user on the domain; or
• the login form still offers password auth for accounts that SSO cannot serve; or
• SigNoz refuses to enable SSO for a domain while the org owner on that domain would be left without a usable auth path, and says so at configuration time.

Actual

The email is accepted, the domain precheck redirects to SSO, and SSO does not authenticate the account. There is no way back to the password form.

Why this is hard to recover from

The usual escape hatches are also unavailable, which is what turns an inconvenience into a permanent lockout:

• No second admin. This is the root account; on a fresh install it may be the only admin.
• Password reset needs email. On a self-hosted install without SMTP configured, no reset mail is delivered. Nothing surfaces the reset link in the UI or logs for an operator to use instead.
• The API cannot substitute. Admin endpoints (GET /api/v2/users, GET /api/v2/orgs/me) correctly return 403 {"code":"authz_forbidden","message":"only admins can access this resource"} for a non-admin service-account API key. Minting an admin key requires logging in — the same thing that is blocked.
• The older recovery routes are gone. On v0.141.1 the v1 auth paths (/api/v1/forgotPassword, /api/v1/resetPassword, /api/v1/getResetPasswordToken) are no longer served and fall through to the frontend catch-all, and /api/v1/user/me returns 501 {"code":"user_deprecated"}.

That leaves editing the metastore by hand as the only remaining option, which requires cluster/filesystem access and carries real risk — the SQLite metastore is in WAL mode and written continuously by a running signoz-0, so it cannot be safely modified in place while the service is up.

Environment

• SigNoz v0.141.1 (GET /api/v1/version → {"version":"v0.141.1","ee":"Y","setupCompleted":true})
• Self-hosted on Kubernetes via the official Helm chart, signoz-0.141.1
• Metastore: bundled SQLite (/var/lib/signoz/signoz.db), no external Postgres
• SSO: Google OAuth
• SMTP: not configured

Suggested fixes

In rough order of value:

1. Guard at configuration time. When enabling SSO for a domain, verify the org owner on that domain can authenticate through it; block or warn otherwise. This prevents the state entirely.
2. Keep a password fallback for the org owner, or expose a "sign in with password instead" affordance on the precheck redirect so an account SSO cannot serve is not stranded.
3. Provide an offline recovery path — a documented admin CLI subcommand on the SigNoz container (reset a user's password, or disable SSO for a domain) so recovery does not require hand-editing a live SQLite file.
4. Surface the reset link when SMTP is unconfigured (operator-visible in logs or the UI), so self-hosted installs without mail are not cut off from the reset flow.

Workaround

None that does not require direct metastore access.