SSO login failed
Symptoms
Section titled “Symptoms”Clicking Sign in with Microsoft/Google ends in an error — at the provider, or back in ServiceOps with a “sign-in failed” message.
The error happens at the provider
Section titled “The error happens at the provider”Redirect URI mismatch (Microsoft AADSTS50011, Google redirect_uri_mismatch) — the URI
registered at the provider differs from the one ServiceOps uses, even by one character.
- Verify: compare the provider’s registered URI with the one shown in Organization → Settings → Identity, character for character — scheme, host, path, trailing slash.
- Fix: correct the registration at the provider. If you serve a custom domain, the callback shown by ServiceOps already accounts for it — register exactly what is shown.
Consent / permission errors — the app registration lacks consent, or an admin restricted user consent.
- Fix: grant admin consent on the app registration (Microsoft), or check the OAuth consent screen configuration and test users (Google).
The provider succeeds, ServiceOps refuses
Section titled “The provider succeeds, ServiceOps refuses”- Expired or wrong client secret — Microsoft secrets expire. Create a new secret and update it in ServiceOps.
- The account matches no user, and provisioning is off — create the user (or enable first-sign-in provisioning), or check that the directory-synced email matches exactly.
- Organization-only mode with the wrong provider — if your organization enforces SSO-only, password login and other providers are refused by design.
After changing anything
Section titled “After changing anything”Use Test sign-in on the identity settings, in a private browser window — cached provider sessions hide fixes and failures alike.