Allow a verified OIDC domain to be shared across multiple organizations (single-tenant / self-hosted deployments)

[iftika1]

Summary

Hive enforces that a verified OIDC email domain can belong to only one organization in the
entire instance. At the same time, both SCIM user provisioning and OIDC sign-in require the
user's email domain to be verified for that specific organization. These two rules are in direct
tension for self-hosted, single-tenant deployments where one company runs Hive and structures
many organizations by line of business, but every user shares one corporate email domain (e.g.
@company.com).

The result: only the first organization to verify company.com can provision or admit
@company.com users. Every other organization is permanently blocked.

Proposal

Add an opt-in, instance-level configuration (env var) listing operator-trusted email domains.
Default is empty → no behavior change (per-org uniqueness preserved for Cloud). When a domain is
listed:

• SCIM email validation (handleEmailValidation) and OIDC sign-in treat the domain as verified for
  any organization, without requiring a per-org oidc_integration_domains row.
• This leaves the strict per-org verification path, the register/verify guards, and the
  only_one_verified_domain_name_idx index completely intact — no schema change. Trusted
  domains simply short-circuit the verified-domain lookup at the consumer.

Sketch:

// consumer check becomes:
if (isTrustedEmailDomain(email, env.trustedEmailDomains)) return ok;
// else fall back to the existing per-org findVerifiedDomainByOIDCIntegrationIdAndDomainName(...)

This is the least invasive option: it doesn't relax the DB uniqueness constraint (so nothing about
Cloud's guarantees changes) and reframes verification from "per-org domain ownership" to
"instance-level operator-declared trust," which matches the single-tenant reality that the operator
(not any one org) owns the domain.

[iftika1]

Our proposed approach: instance-trusted email domains (opt-in, default empty) — an operator-declared list of domains owned at the instance level and shared across orgs, AUTH_ORGANIZATION_TRUSTED_EMAIL_DOMAINS (comma-separated, default empty). Effect defined per gate:

• per-org gates (SCIM, email step-up): treat as verified for any org;
• global gates (non-OIDC sign-up, cross-org sign-in): treat as not-foreign → skip the oidcForVerifiedDomainsRequired block.

// per-org gates: centralize so every current/future consumer inherits it
findVerifiedDomainByOIDCIntegrationIdAndDomainName(oidcId, domain) {
  if (isEmailDomainTrusted(domain, trusted)) return SYNTHETIC_VERIFIED; // verified for any org
  return <existing per-org query>;
}
// global gates: an instance-owned domain is not "foreign" → skip the block
if (isEmailDomainTrusted(email, trusted)) { /* skip the oidcForVerifiedDomainsRequired cross-org block */ }

isEmailDomainTrusted(email, list) is a trivial domain-membership check; the list is parsed in environment.ts and threaded into the SCIM plugin and the auth strategy.

What stays untouched: no schema change — only_one_verified_domain_name_idx, registerDomain(), updateDomainVerifiedAt(), and findVerifiedDomainByName are unchanged; trusted domains simply never need an oidc_integration_domains row. Empty default ⇒ Cloud behavior is unchanged.

Alternative: relax only_one_verified_domain_name_idx to (domain_name, oidc_integration_id) and drop the register/verify guards, so each org verifies the shared domain independently. Keeps verification strictly per-org, but needs a migration, reworks findVerifiedDomainByName (it's maybeOne, so two verified rows would throw) and its callers, and forces redundant DNS proofs of the same corporate domain in every org.

We're leaning toward the opt-in trusted list. A couple questions:

1. Does the "instance-trusted domains, effect-defined-per-gate" shape match what you'd want upstream, or would you prefer the per-(org, domain) route (or a third shape)?
2. Do you agree the two cross-org gates should skip enforcement for a trusted (instance-owned) domain?
3. Is AUTH_ORGANIZATION_TRUSTED_EMAIL_DOMAINS an acceptable name/surface (env var), or would you prefer an instance/DB setting?
4. Scope: land SCIM + email step-up first, with the two OIDC-enforcement gates as a follow-up — or all four together?