Single sign-on (SSO)

Business and above

Single sign-on lets your users sign in to Scopingly with your organization's own identity provider. Each organization configures its own credentials per provider, so you are not sharing a deployment-wide app registration with other tenants.

Supported providers

You can configure any of:

• Google
• Microsoft
• Okta
• OneLogin
• PingID

For Okta, OneLogin, and PingID you also supply your tenant's issuer (the base URL of your identity provider). Google and Microsoft use OAuth; the others use OIDC.

Configuring SSO

SSO is managed by org admins in the SSO Configuration area of Admin settings. For each provider you enable, you supply the client credentials issued by your identity provider.

• Per-org override. A configured, enabled provider row for your organization takes precedence over any deployment-wide default. If you don't configure a provider, Scopingly falls back to its environment default (where one exists).
• Secrets are encrypted. Client secrets are stored encrypted at rest, never in plaintext.
• Reads are masked. When you view your SSO configuration, secret values are masked — the console never echoes a stored secret back to you.

SSO email-domain mapping is separate

Mapping an email domain to your org (so a user signing in with @acme.com is routed to the Acme tenant) is distinct from mapping a custom vanity hostname to your tenant. They are two different trust decisions and are configured separately.

Once configured, your provider appears as a sign-in option on the login page, and the OAuth/OIDC round-trip carries the resolved organization through so users land in the right tenant.

Availability

SSO is a Business and above entitlement. Enabling or editing SSO providers requires the sso feature, which your plan must unlock. Viewing existing configuration and removing a provider stay available even to a downgraded org so it can tear down cleanly. See the feature comparison.

Downgrade behavior

Because SSO is a Business+ entitlement, an organization that downgrades below Business (to Pro or Free) loses the sso feature. Scopingly handles this without stranding your users:

1. SSO login is refused for the downgraded org once the feature is lost.
2. Affected active users are migrated to password login. Their account is switched to a local account and they are emailed a one-time set-password link so they can regain access. No user is left unable to sign in.
3. Forgot Password becomes the durable recovery path. Even if the emailed link lapses, a migrated user can use the standard Forgot Password flow to set a password, because their account is now a local account.
4. Re-upgrading re-enables SSO. If you return to Business or above, the sso entitlement is restored and the next SSO sign-in re-binds the user to your identity provider automatically — no manual repair.

Rollout note

Login-time enforcement of the SSO entitlement is gated behind a rollout flag and is dark by default. Until it is enabled for your environment, existing SSO users continue to sign in as before after a downgrade. When enforcement is on, the migration above runs automatically. Your stored provider configuration is never torn down on downgrade, so a re-upgrade restores SSO instantly.

Related

• Custom domains — vanity hostnames (a different feature)
• Security & privacy
• Roles & permissions
• Plans · Feature comparison