What is single sign-on (SSO)?

Single sign-on: definition and benefits

Without SSO, every employee has a separate account with a separate password for every application: email, inventory system, time tracking, ticket system and customer portal. This leads to password fatigue, reused passwords and many support requests about forgotten credentials. SSO bundles the login in one place.

Users sign in once at the central identity service, the identity provider (IdP), such as Microsoft Entra ID, Okta or the open-source service Keycloak. The connected applications, the service providers, receive a confirmation of identity and let the user in. This is more than “same sign-on,” where the same password merely applies everywhere.

How SSO works

Technically, SSO relies on standardized protocols. SAML 2.0 is widespread above all in enterprise applications, OpenID Connect—built on OAuth 2.0—in modern web and mobile applications. Both transmit a signed confirmation of identity along with attributes such as name, email address or group membership.

When a user opens an application, it redirects them to the identity provider. If a session already exists there, the user goes straight back to the application without entering anything. Otherwise, the login takes place—ideally with two-factor authentication—and then applies to all connected applications.

Real-world example: offboarding in a mid-sized company

A machine builder with 80 employees uses a dozen applications. When someone leaves the company, the IT team has to block twelve accounts individually; in practice, a forgotten access easily stays active, for example in the customer portal or ticket system, and nobody notices.

With SSO, the account is deactivated centrally, and new logins are immediately impossible in all connected applications; existing sessions expire shortly afterwards, depending on configuration. New employees get the right access immediately through groups, and two-factor authentication can be enforced in one place.

Benefits, limits and common mistakes

SSO increases convenience and security because fewer passwords are in circulation and rules apply centrally. At the same time, the identity provider becomes a critical point: if it fails or an account is compromised, many applications are affected at once. This dependency has to be secured. Typical mistakes:

• Running SSO without two-factor authentication for the central account
• Forgetting an emergency access (break-glass account) for when the identity service is down
• Connecting applications without assigning roles and permissions cleanly
• Long session lifetimes, so access lingers after someone leaves
• Letting old local accounts keep running in parallel

What businesses should look out for

Clarify in advance which applications support SSO (SAML or OpenID Connect), who maintains the identities and how roles are assigned. If you already use Microsoft 365, you usually already have an identity service in house with Entra ID. Nano Concepts connects customer portals, apps and web applications to your identity service via OpenID Connect or SAML.