Single Sign-On (SSO) enables users to access multiple applications with one set of credentials. In Supportbench, SSO simplifies login, enhances security, and supports enterprise authentication setups (e.g., via Microsoft Entra ID).
On the SB login page (Login into Supportbench) you’ll see three clear methods:
Standard Email + Password entry.
Sign in with Microsoft — Redirect to Microsoft’s authentication flow.
Sign in with Google — Redirect to Google’s authentication flow.
Fewer credentials for users to remember → lower support effort.
Improved security, especially when used with enterprise identity features (MFA, conditional access).
Centralised user lifecycle management if tied to your identity provider (e.g., Microsoft Entra).
Faster user onboarding/offboarding because you manage access in your ID-system rather than manually in SB.
Below is a typical flow when your organisation uses Microsoft and wants to use SB with SSO:
On the SB login page the user clicks Sign in with Microsoft.
SB redirects to Microsoft’s authentication page (via your Azure/Entra tenant).
User enters their Microsoft / Azure AD credentials and passes MFA if required.
Microsoft issues a token back to SB verifying user identity and (optionally) group membership or roles.
SB evaluates the token, matches the user to the SB account (or auto-provisions if enabled) and grants access.
User is redirected into their SB dashboard.
Enforce Multi-Factor Authentication (MFA) in your identity provider - SB supports the downstream benefit of that.
Regularly audit who has access to SB, and whether the SSO integration is mapping correctly to current roles/groups.
De-provision promptly: when a user leaves your organisation, disable their account in your ID system and access to SB should automatically cut off.
Monitor login success/failure metrics in SB and in your identity provider for unusual patterns (failed SSO logins, account lockouts).
Keep the SB system of record for which users are assigned SB-roles, but ensure assignment flows are aligned with your identity source.
Issue: “Sign in with Microsoft” fails or asks again for credentials repeatedly → check that the redirect URI configured in Azure matches exactly what SB expects, and that the application is set to allow the proper account types.
Issue: User logs in via Microsoft but gets a “no access” or “account not found” message in SB → ensure the Microsoft account’s email claim matches an existing SB account, or update provisioning settings in SB to allow auto-creation.
Issue: Legacy password logins still allowed even though you prefer SSO only → in SB admin settings you should disable standard username/password login if you want to mandate SSO.
Issue: Users from multiple companies / tenants → SB’s multi-tenant login (“Select company” prompt) may require you to map the correct tenant and company within SB so users land in the correct SB instance. support.supportbench.net
Enabling SSO for Supportbench provides ease-of-use for end users, stronger security when coupled with enterprise identity controls, and centralised administration of access. When properly configured, the “Sign in with Microsoft” (or Google) experience becomes seamless — users click once and they’re in, while admins retain control in their identity platform.
SB-roles, but ensure assignment flows are aligned with your identity source.
Was this article helpful?
Thank you for your feedback!
You are related to multiple companies. Please select the company you wish to login as.