Is SSO less secure because it is a single point of failure?

The central account is a concentrated target, but it is far easier to defend one strongly protected identity than dozens of scattered passwords. With MFA, adaptive policies, and session monitoring at the IdP, SSO delivers a net security gain for almost every organization.

What is the difference between SSO and password managers?

A password manager stores many passwords and fills them in; each application still verifies its own credential. SSO removes those per-application passwords entirely by having applications trust tokens from a central identity provider. SSO gives IT centralized control and instant deprovisioning, which password managers cannot.

Can SSO work with on-premises and legacy applications?

Yes. Older applications can join SSO through headers, Kerberos or IWA, LDAP and RADIUS bridges, or reverse-proxy patterns when they do not support SAML or OIDC natively. This lets a single policy cover both modern SaaS and legacy infrastructure.

Single Sign-On (SSO)

What is Single Sign-On (SSO)?

SSO lets users authenticate once and access many applications without signing in again, using a trusted central identity provider.

Last updated: 13 July 2026

How SSO works

With SSO, applications stop verifying passwords themselves and instead delegate authentication to a central identity provider (IdP). When a user opens an application, it redirects them to the IdP. If the user already has an active session, the IdP silently issues a signed assertion or token; if not, it prompts them to authenticate first.

The application validates the cryptographic signature on that token and starts a local session. The two dominant standards for this exchange are SAML 2.0, common in enterprise software, and OpenID Connect, which is built on OAuth 2.0 and favored by modern web and mobile applications. Either way, the user password never touches the application.

Why SSO matters

Every additional password an employee manages is another credential that can be phished, reused, or forgotten. SSO collapses dozens of passwords into one strongly protected identity, which reduces the attack surface and concentrates security controls such as MFA and risk policies at a single enforcement point.

The operational gains are just as concrete. Help desks spend less time on password resets, users stop losing minutes to repeated logins, and when someone leaves the company, disabling one account cuts access to every connected application at once. That last point makes SSO one of the most effective offboarding controls available.

Implementing SSO in practice

Rollouts usually begin with the applications employees touch daily, such as email, collaboration, and HR tools, then expand outward. Each application is connected to the IdP through SAML or OIDC, either from a pre-built catalog entry or a custom integration. Pairing SSO with MFA at the IdP is considered mandatory, since the single session now unlocks everything behind it.

Legacy applications that only speak LDAP, RADIUS, or Kerberos need protocol bridging so they can participate in the same central policy. Monosign supports SAML 2.0, OIDC with PKCE, WS-Fed, and Kerberos alongside a catalog of more than 7,000 pre-built application integrations.

Frequently asked questions

Is SSO less secure because it is a single point of failure?: The central account is a concentrated target, but it is far easier to defend one strongly protected identity than dozens of scattered passwords. With MFA, adaptive policies, and session monitoring at the IdP, SSO delivers a net security gain for almost every organization.
What is the difference between SSO and password managers?: A password manager stores many passwords and fills them in; each application still verifies its own credential. SSO removes those per-application passwords entirely by having applications trust tokens from a central identity provider. SSO gives IT centralized control and instant deprovisioning, which password managers cannot.
Can SSO work with on-premises and legacy applications?: Yes. Older applications can join SSO through headers, Kerberos or IWA, LDAP and RADIUS bridges, or reverse-proxy patterns when they do not support SAML or OIDC natively. This lets a single policy cover both modern SaaS and legacy infrastructure.