Single sign-on

Single sign-on (SSO) moves authentication out of individual business applications and into a central identity provider (IdP). Once a person has signed in there, the IdP issues the connected applications – the service providers or relying parties – a signed token confirming that authentication has taken place. Two open standards dominate in practice: SAML 2.0, which transports XML-based assertions via browser redirects or POST bindings and is widespread in traditional enterprise and public-sector applications, and OpenID Connect (OIDC), an identity layer on top of OAuth 2.0 that uses JSON Web Tokens and has become the default for web, mobile and API scenarios. Neither standard passes passwords to the target application; they transmit only a verifiable statement about the identity and, depending on configuration, additional attributes such as group or role membership.

From an information security perspective, SSO is above all a lever for access control and accountability. Passwords exist in only one place, which removes password reuse and local credential stores from business applications. Strong authentication – in particular phishing-resistant multi-factor authentication based on FIDO2/WebAuthn – has to be implemented and maintained only once and then protects every connected system. Joiner-mover-leaver processes can likewise be steered centrally: if an account is disabled in the directory service, the person immediately loses access to all connected applications. SSO therefore directly supports the access control and identity management requirements that Article 21(2) of the NIS2 Directive, ISO/IEC 27001 (A.5.15 to A.5.18, A.8.5) and the BSI IT-Grundschutz module ORP.4 place on organisations.

Bundling authentication also concentrates risk, however. The identity provider becomes a single point of failure and a highly attractive target. If it goes down, access to every connected application is blocked; if a privileged IdP account or a signing key is compromised, an attacker can impersonate any user towards all service providers. Typical attack patterns include theft of valid session tokens, MFA fatigue attacks, manipulation of metadata or signature validation, and the abusive registration of attacker-controlled applications in the IdP. Appropriate countermeasures are a hardened and redundant IdP infrastructure, strict privileged access management for administrators, disciplined key management with regular rollover, short token lifetimes combined with single logout, complete logging of authentication events into a SIEM, and documented emergency access (break-glass accounts) for an identity provider outage.