Require SSO for sign-in

When Require SSO is on, password sign-in, magic links, and Google or Microsoft sign-in are all rejected for members of your account. Only your identity provider can let users in. Active sessions stay valid until their normal idle timeout, so turning it on does not bounce people out of work in progress.

Before you enable it

You must have a working SAML 2.0 connection saved and the in-app Test connection check must have passed at least once. The setting is deliberately disabled until then so a typo in your IdP URL or a misformatted certificate cannot lock the account out.

If your last successful test is more than thirty days old we surface a soft warning. Cert rolls, IdP-side config changes, and SAML response shape changes can all rot the integration silently; re-run the test before enforcing.

Steps

1. Save and test your SAML configuration

   Open SSO settings and finish your SAML configuration. Run Test connection until it reports the configuration is valid.

2. Open the Require SSO confirmation

   In the Enforcement section, choose Require SSO. The modal explains the consequences and shows how many account members will be affected.

3. Enter your two-factor code

   Enforcement requires a fresh code from your authenticator app or one of your recovery codes. This is a step-up confirmation; it is not stored.

4. Confirm

   Confirm the change. The setting takes effect immediately for new sign-ins. Active sessions stay valid until their normal idle timeout.

What your members see

When a member tries to sign in with a password, magic link, or OAuth provider, they see a violet "Continue with SSO" panel with a one-click button to your identity provider. The same panel appears on the sign-up, forgot-password, and reset-password pages so they cannot create a parallel password-only account or mint a useless reset token.

The password-policy section of Security settings is hidden while Require SSO is on, because none of those rules can take effect. The two-factor toggle still appears, but its scope is narrowed to step-up confirmations inside the app (disabling Require SSO, changing the SAML config, sensitive admin actions); sign-in 2FA is enforced by your identity provider.

Plan downgrades

Require SSO can only stay on while your plan includes SSO. If you initiate a plan change that drops SSO entitlement we refuse the downgrade until you turn the requirement off. If the plan drops automatically (failed renewal, scheduled downgrade, manual override from the support team) we turn the requirement off for you and email a password-setup link to anyone who would otherwise have no way in.

Turning it off

You can turn the requirement off at any time from the same Enforcement section. Other sign-in methods become available again on the next request; active sessions are unaffected. Optionally sign every active session out during the same confirmation if you suspect a security incident.

Disabling SAML entirely

If you remove the SAML configuration (not just the Require SSO toggle), our disable flow looks at every member and counts the ones who would have no other way in. By default we email those members a password-setup link that uses the existing Forgot password flow. The confirmation modal shows the count and lets you opt out of either the email blast or the optional session revocation.

A note about active sessions

Turning Require SSO on does not sign anyone out. Existing access tokens stay valid until normal idle expiry, and /auth/refresh keeps issuing new ones. That is deliberate, so a policy change at 4pm does not kick everyone out of the workspace mid-meeting. If you want to force every member to re-authenticate through your IdP immediately, tick "Sign everyone out now" in the disable / require confirmation modal. Once revoked, the next request from each device bounces to your IdP.

What if everyone is locked out?

If the integration breaks while Require SSO is on (cert expired on the IdP side, the IdP itself is down, your in-app admin lost their authenticator), the account looks locked out from the outside. Contact Queringo support: there is an internal break-glass procedure that clears the requirement, captures the reason, and emails affected members a password-setup link in the same step. If the first round of emails partially fails (bouncing addresses, temporary mail provider trouble), support can re-run the blast with a force flag that bypasses the dedupe window.