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
- Activate another SSO config first, then deactivate this one
- Temporarily disable SSO enforcement in settings before deactivating the provider
- Keep the config activated and only update its credentials/endpoints
- 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
- Never uncheck 'activated' on the sole active provider while enforcement is on
- Deactivate enforcement in settings before removing the last SSO provider
- Audit activated flags after every SSO config edit
- Keep a second provider configured as a fallback
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
- Error constructing OIDC authentication strategy - ${err}
- Configuration invalid. Must contain clientID, clientSecret,
- No google configuration found
- Configuration invalid. Must contain google clientID and clie
- Error constructing google authentication strategy: ${err}
AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29).
Data as JSON: /api/errors/207743aea6306b29.
Report an issue: GitHub.