Back to glossary
S
Definition

SSO IT definition

Single Sign-On: an authentication pattern that lets a user log in once to access multiple applications.

SSO (Single Sign-On) is the authentication pattern that lets a user log in once to access a set of applications, without re-authenticating per service. It is one of the cornerstones of modern IAM and a powerful lever for security, productivity, and IT governance.

Context makes SSO unavoidable: an average employee uses more than 35 applications a week (Okta Businesses at Work 2024), and per a LastPass report each user manages on average 191 work passwords. Without SSO that volume is unmanageable, leading to weak, reused, shared passwords — all open doors to attackers.

How SSO works

SSO relies on an Identity Provider (IdP) — Microsoft Entra ID, Okta, Google Workspace, Ping Identity, ForgeRock — that authenticates the user and issues target applications (Service Providers, SP) a signed proof of identity.

The typical flow:

  1. The user tries to reach an application.
  2. The application redirects to the IdP.
  3. If the user is not already authenticated, the IdP asks for credentials (and the MFA second factor).
  4. The IdP issues a signed token that the application accepts as proof of identity.
  5. The application grants access without asking for its own password.

The password is known only to the IdP. Applications never see it.

Standard SSO protocols

  • SAML 2.0: classic enterprise SSO standard, XML-based, still majority in traditional web apps.
  • OpenID Connect (OIDC): modern OAuth 2.0-based version, JSON, better fit for mobile and SPAs.
  • OAuth 2.0: strictly an authorization protocol, but often used alongside OIDC for authentication.
  • Kerberos: historical Active Directory standard, dominant in Windows LAN.
  • CAS: open-source protocol widespread in French higher education.

SSO benefits

  • Stronger security: fewer passwords = less leak surface. Combined with MFA, SSO dramatically reduces credential-stuffing attacks.
  • Productivity: per Okta, SSO saves 5 to 15 minutes per user per day — several workdays per year.
  • Governance: one revocation point. When an employee leaves, disabling the IdP account cuts access to every connected application.
  • Audit and compliance: centralized authentication logs, required by ISO 27001, SOC 2, GDPR, NIS2.
  • [Shadow IT](/en/glossary/shadow-it): detection: applications not behind SSO are identifiable and represent measurable risk.

SSO ≠ MFA ≠ password manager

Three complementary, often confused mechanisms:

  • SSO: one login for many applications.
  • MFA: a second factor (TOTP, FIDO2, push) at authentication time.
  • Password manager: stores and autofills passwords — useful, but doesn't remove passwords.

SSO without MFA is risky (one compromised password opens everything). MFA without SSO leaves the account-sprawl problem. The combination SSO + MFA is the modern minimum security standard in business.

SSO and regulatory compliance

Major regulations mandate or strongly recommend SSO:

  • NIS2: strong authentication, access traceability, least privilege.
  • DORA: identity and access management, continuous monitoring.
  • GDPR: pseudonymization and minimization, access trails for personal data.
  • ISO 27001: (A.9 access control): centralization and access review.
  • SOC 2: type II requires evidence of regular access review, made easier by SSO.

Limits and pitfalls

  • Single point of failure: if the IdP is down, the whole IT estate is unreachable. Hence the importance of IdP high availability and break-glass procedures.
  • Partial coverage: not every app supports SAML/OIDC. Legacy or niche apps may stay on local authentication — blind spots.
  • Propagation risk: a compromised IdP account opens every connected app. MFA is therefore non-negotiable, ideally phishing-resistant (FIDO2).
  • Fine-grained permissions: SSO authenticates, it doesn't authorize. Role-based permissions (RBAC) stay with each application.

SSO and application visibility

A CIO can only steer SSO strategy if she knows which applications are used in the IT estate. Kabeen surfaces every application employees actually use — including outside SSO — and lets you prioritize attaching them to the central IdP to close blind spots.

Frequently asked questions

What is SSO?

+

SSO (Single Sign-On) is an authentication pattern that lets a user log in once to access a set of applications, without re-authenticating each time. It relies on a central identity provider (Microsoft Entra ID, Okta, Google Workspace) that authenticates the user and issues applications a signed proof of identity.

What is the difference between SSO and MFA?

+

SSO enables one login for multiple applications. MFA (Multi-Factor Authentication) requires a second authentication factor (TOTP code, FIDO2 key, mobile push) on top of the password. The two are complementary: SSO without MFA is risky (one compromised password opens everything); MFA without SSO leaves account-sprawl unsolved. SSO + MFA is the current security baseline.

Which SSO protocols exist?

+

Reference standards are SAML 2.0 (legacy, XML, dominant in enterprise web apps), OpenID Connect / OAuth 2.0 (modern, JSON, fit for mobile and SPAs), Kerberos (Active Directory, dominant in Windows LANs), and CAS (open source, common in French higher education). Most modern SaaS vendors support at least SAML 2.0 and OIDC.

What are the risks of SSO?

+

Three main risks: (1) single point of failure — if the IdP is down, every app becomes unreachable, hence the need for high availability; (2) propagation of compromise — a hacked IdP account opens every connected app, hence mandatory MFA; (3) partial coverage — apps outside SSO remain blind spots. Good SSO governance enforces phishing-resistant MFA (FIDO2) and tracks apps not yet covered.

Need help mapping your IT landscape?

Kabeen helps you inventory, analyze and optimize your application portfolio.

Try for free