Budibase/budibase · error

Configuration cannot be deactivated while SSO is enforced

Error message

Configuration cannot be deactivated while SSO is enforced

What it means

verifySSOConfig runs for Google/OIDC config saves. When SSO enforcement is active it re-checks hasActivatedConfig() over the merged set of SSO configs (including the update being applied). If the update would leave zero activated SSO configs, enforcement could not be satisfied, so the change is rejected.

Source

Thrown at packages/worker/src/api/controllers/global/configs.ts:224

    config.faviconUrl = existingConfig.faviconUrl
    config.faviconUrlEtag = existingConfig.faviconUrlEtag
  }
}

async function verifySSOConfig(type: SSOConfigType, config: SSOConfig) {
  const settings = await configs.getSettingsConfig()
  if (settings.isSSOEnforced && !config.activated) {
    // config is being saved as deactivated
    // ensure there is at least one other activated sso config
    const ssoConfigs = await getSSOConfigs()

    // overwrite the config being updated
    // to reflect the desired state
    ssoConfigs[type] = config

    const activated = await hasActivatedConfig(ssoConfigs)
    if (!activated) {
      throw new Error(
        "Configuration cannot be deactivated while SSO is enforced"
      )
    }
  }
}

async function processGoogleConfig(
  config: GoogleInnerConfig,
  existing?: GoogleInnerConfig
) {
  await verifySSOConfig(ConfigType.GOOGLE, config)

  if (existing && config.clientSecret === PASSWORD_REPLACEMENT) {
    config.clientSecret = existing.clientSecret
  }
}

async function processOIDCConfig(config: OIDCConfigs, existing?: OIDCConfigs) {

View on GitHub (pinned to a81a902e9a)

Solutions

  1. Activate another SSO config first, then deactivate this one
  2. Temporarily disable SSO enforcement in settings before deactivating the provider
  3. Keep the config activated and only update its credentials/endpoints
  4. Check the payload: ensure activated is not accidentally set to false on the only active config

Example fix

// before
{ "type": "oidc", "config": { "activated": false } } // last active provider
// after
// disable enforcement first, then deactivate the provider
Defensive patterns

Strategy: validation

Validate before calling

const others = ssoConfigs.filter(c => c.type !== beingEdited.type)
const otherActivated = others.some(c => c.config?.activated)
if (settings.isSSOEnforced && !otherActivated && !newConfig.activated) {
  // block: this would leave no activated provider while SSO is enforced
}

Try / catch

try {
  await configApi.save(ssoConfig)
} catch (err) {
  if (err.message.includes("Configuration cannot be deactivated while SSO is enforced")) {
    // disable enforcement first or activate a second provider
  } else { throw err }
}

Prevention

When it happens

Trigger: Saving a Google or OIDC config that deactivates the last activated SSO config (e.g. activated=false, or deleting/overwriting the sole active config) while isSSOEnforced is on.

Common situations: Admin edits an SSO provider and unchecks 'activated' not realizing it is the only active provider while SSO enforcement is enabled; tenant-wide lockout prevention kicks in.

Related errors


AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29). Data as JSON: /api/errors/207743aea6306b29. Report an issue: GitHub.