Glossary · simply explained

SSO (Single Sign-on)

Single sign-on (SSO) means users authenticate once with the central identity provider and then get access to all connected applications — without further passwords. Technically, standards such as SAML and OpenID Connect handle the secure handover of identity.

SSO is far more than convenience: it centralises control. Authentication rules, MFA and account lockout act in one place for all services — and on exit one click closes all access.

How does SSO work technically?

An application that sees an unauthenticated user redirects them to the identity provider (IdP). Login happens there — ideally with MFA or a passkey — and the IdP issues a signed ticket (SAML assertion or OIDC token) the application trusts. Further applications receive their tickets from the existing IdP session without a new login.

Security thus concentrates on the IdP session: its hardening — strong authentication, session duration, context checks via conditional access — determines the protection level of all connected services.

What SSO gives the company

  • One place for rules: MFA, passkeys and access policies apply everywhere at once.
  • Clean offboarding: one locked account closes all applications.
  • Less password sprawl — and less reuse across services.
  • Full login transparency for detection and evidence.

Frequently asked questions about SSO (Single Sign-on)

Is SSO not a single point of failure?

The IdP becomes a critical service — so you choose highly available providers, harden login with MFA or passkeys and define emergency access. The alternative, dozens of individual passwords, is far riskier and less controllable in total.

What is the difference between SAML and OpenID Connect?

Both solve the same problem — secure identity handover. SAML is the established XML standard of classic enterprise applications; OpenID Connect, built on OAuth 2.0, is the more modern, lightweight method for web and apps. Good IdPs speak both.

Does SSO make passwords obsolete?

It reduces them to a single login — and that one can be passwordless: passkeys or hardware tokens at the IdP replace the password entirely. That combines the convenience of SSO with phishing-resistant authentication.

How do legacy applications without SSO support join?

Via access proxies: solutions such as ZTNA platforms put the central login in front of arbitrary internal applications, even if these do not speak SAML or OIDC themselves. Legacy systems benefit from MFA and central control too.

What happens if an SSO account is compromised?

Then fast, central action is the advantage: lock the account, end sessions — all applications are protected immediately. In addition, conditional access rules and anomaly detection at the IdP limit what an attacker can achieve with a stolen session at all.

Open questions about this in your environment? KAEMI advises you in line with your requirements and can also take over ongoing management.