Was ist SSO (Single Sign-On)?

Single Sign-On (SSO) eliminiert die Passwort-Müdigkeit, konsolidiert Identitäten und bildet den zentralen Einstiegspunkt moderner IT-Sicherheitsarchitekturen.

Die fortschreitende Digitalisierung und der flächendeckende Einsatz von Software-as-a-Service-Lösungen (SaaS) haben die tägliche Arbeitsumgebung von Mitarbeitern in modernen Unternehmen drastisch verändert. Ein durchschnittlicher Angestellter nutzt heute für seine operativen Aufgaben dutzende verschiedene Plattformen: vom E-Mail-Programm und dem CRM-System über Zeiterfassungs-Tools bis hin zu spezifischen Projektmanagement-Plattformen. Müsste der Anwender für jede dieser Anwendungen ein eigenes, komplexes Passwort erstellen, auswendig lernen und regelmäßig ändern, führt dies unweigerlich zum Phänomen der Passwort-Müdigkeit (Password Fatigue).

In der informationstechnischen Realität führt dieser Zustand zu gravierenden Sicherheitsrisiken: Mitarbeiter wählen unsichere, leicht zu erratende Passwörter, verwenden dieselbe Zeichenkette plattformübergreifend wieder oder notieren Zugangsdaten auf physischen Notizzetteln. Gleichzeitig verliert die interne IT-Abteilung vollständig die Kontrolle darüber, wer auf welche externen Systeme zugreift, und das Onboarding sowie Offboarding von Mitarbeitern wird zu einer administrativen Herausforderung.

Single Sign-On, universell als SSO abgekürzt, löst dieses strukturelle Identitätsdilemma vollständig auf. Es handelt sich um ein hochentwickeltes Authentifizierungsverfahren, das es einem Benutzer ermöglicht, sich ein einziges Mal an einer zentralen Instanz zu authentifizieren, um anschließend automatisch und ohne erneute Passworteingabe Zugriff auf alle für ihn freigegebenen Anwendungen, Systeme und Dienste zu erhalten.

Die technologische Kernarchitektur: Das Vertrauensverhältnis (IdP vs. SP)

Das grundlegende Funktionsprinzip von Single Sign-On basiert auf der vollständigen Entkopplung der Identitätsprüfung von der eigentlichen Anwendungslogik. Anstatt dass jede Anwendung (z. B. ein Cloud-Speicher) die Zugangsdaten des Nutzers selbst speichert und überprüft, delegiert sie diese Aufgabe an eine spezialisierte, übergeordnete Instanz.

In der Facharchitektur unterscheidet man hierbei zwei fundamentale Rollen, deren kryptografisch abgesichertes Zusammenspiel das SSO-Gefüge bildet:

• Identity Provider (IdP – Identitätsanbieter): Dies ist das administrative und technologische Gehirn des Identitätsraums (z. B. Microsoft Entra ID, Okta oder Ping Identity). Der IdP verwaltet die Benutzerdatenbank, erzwingt Sicherheitsrichtlinien (wie Passworthärten und Mehrfaktor-Authentifizierung) und führt die physische Überprüfung des Nutzers durch. Nur der IdP sieht jemals das Passwort des Benutzers.
• Service Provider (SP – Dienstanbieter): Dies ist die eigentliche Nutzanwendung (z. B. Salesforce, Slack oder eine interne HR-App), auf die der Benutzer zugreifen möchte. Der Service Provider besitzt keine eigenen Passwörter für die Nutzer, sondern verlässt sich blind auf das Urteil des Identity Providers.

Damit dieses Modell funktioniert, muss im Vorfeld eine digitale Vertrauensbeziehung (Trust Relationship) zwischen dem Service Provider und dem Identity Provider eingerichtet werden. Technisch geschieht dies durch den Austausch von Metadaten, Konfigurations-URLs und vor allem kryptografischen Zertifikaten (Public-Key-Infrastruktur). Der Service Provider hinterlegt den öffentlichen Schlüssel (Public Key) des Identity Providers. Jede Bestätigung über eine erfolgreiche Anmeldung, die der IdP ausstellt, wird mit dessen privatem Schlüssel (Private Key) digital signiert. Der Service Provider kann diese Signatur mathematisch prüfen und somit fälschungssicher verifizieren, dass die Freigabe direkt von der autorisierten Identitätszentrale stammt.

Die führenden SSO-Protokolle im Überblick

Für den standardisierten Datenaustausch von Identitäts- und Autorisierungsinformationen zwischen IdP und SP haben sich im Laufe der Technologiegeschichte verschiedene offene Protokolle etabliert, die jeweils für spezifische Einsatzszenarien optimiert sind.

SAML 2.0 (Security Assertion Markup Language)

SAML 2.0 ist der bewährte, XML-basierte Ur-Standard des föderierten Identitätsmanagements, spezifiziert durch das OASIS-Konsortium. Es wird vorwiegend im klassischen Enterprise-Umfeld und für B2B-SaaS-Anwendungen eingesetzt. SAML überträgt Identitätsdaten in Form von sogenannten Assertions (Zusicherungen) über den Browser des Nutzers. Die technischen Spezifikationen und geschichtlichen Dokumentationen des Standards können über das offizielle Portal eingesehen werden.

OpenID Connect (OIDC)

OpenID Connect bildet im Jahr 2026 den modernen Standard für Web- und Mobilanwendungen. Es handelt sich um eine leichtgewichtige Identitätsschicht, die direkt auf dem Autorisierungs-Framework OAuth 2.0 aufbaut. Anstatt sperriger XML-Strukturen nutzt OIDC das JSON-Datenformat und überträgt die Identitätsdaten in Form von digital signierten JSON Web Tokens (JWT). Die Weiterentwicklung und Standardisierung dieses Protokolls wird von der OpenID Foundation koordiniert.

Kerberos

Kerberos ist ein ticketbasiertes Netzwerk-Authentifizierungsprotokoll, das primär in lokalen Firmennetzwerken (On-Premises) und innerhalb von Microsoft Active Directory-Umgebungen eingesetzt wird. Es ist für das klassische Intranet optimiert und erlaubt ein nahtloses SSO beim Zugriff auf lokale Datei-Server oder interne Webseiten, eignet sich aufgrund seiner technologischen Architektur jedoch nicht für die direkte Kommunikation mit Cloud-Diensten über das öffentliche Internet.

Der schrittweise Ablauf einer föderierten SSO-Anmeldung (OIDC / SAML)

Wenn ein Mitarbeiter im operativen Betrieb eine geschützte Cloud-Anwendung aufruft, läuft im Hintergrund ein exakt choreografierter Kommunikationsfluss ab, der für den Endanwender unsichtbar bleibt:

1. Anwendungsaufruf: Der Benutzer navigiert im Browser zur URL des Service Providers (z. B. der internen Projekt-App).
2. Umleitung (Redirect): Der Service Provider erkennt, dass der Benutzer keine aktive Sitzung (Session) besitzt. Er generiert eine Authentifizierungsanfrage und leitet den Browser des Benutzers automatisch zur Login-Seite des vorkonfigurierten Identity Providers um.
3. Zentrale Authentifizierung: Der Benutzer kommt auf der Seite des IdP an. Hat er sich heute bereits an einem anderen System angemeldet, erkennt der IdP das bestehende Session-Cookie und überspringt den Login. Falls nicht, muss der Benutzer nun seine primären Zugangsdaten (Passwort und zwingend einen zweiten Faktor via MFA) eingeben.
4. Token-Generierung: Nach erfolgreicher Verifizierung erstellt der Identity Provider ein digitales Token (z. B. ein ID-Token als JWT bei OIDC). Dieses Token enthält standardisierte Behauptungen (Claims) über den Nutzer – wie die eindeutige Benutzer-ID, die E-Mail-Adresse und den Gültigkeitszeitraum. Der IdP signiert dieses Token kryptografisch mit seinem Private Key.
5. Rückleitung und Übergabe: Der IdP leitet den Browser des Benutzers zurück zur vordefinierten Assertion Consumer Service (ACS) URL des Service Providers und übergibt das signierte Token im HTTP-Datenstrom.
6. Validierung und Sitzungseröffnung: Der Service Provider nimmt das Token entgegen, überprüft die digitale Signatur mithilfe des hinterlegten Public Keys des IdP und stellt sicher, dass das Token gültig und nicht abgelaufen ist. Ist die mathematische Prüfung erfolgreich, öffnet der SP die Anwendungssitzung und der Benutzer ist eingeloggt.

Systematischer Vergleich der Identitätsprotokolle

Die operativen, strukturellen und einsatzspezifischen Unterschiede der drei primären SSO-Technologien lassen sich anhand zentraler Systemparameter direkt gegenüberstellen:

Kriterium	SAML 2.0	OpenID Connect (OIDC)	Kerberos
Datenformat	XML (Extensible Markup Language)	JSON (JavaScript Object Notation)	Binäre Datenstrukturen (ASN.1)
Transportschicht	HTTP / Webbrowser-Redirects	HTTP / REST-APIs / Web-Standards	Dedizierte UDP/TCP-Ports (Port 88)
Primärer Fokus	Enterprise-B2B, Legacy-SaaS-Apps	Cloud-native Apps, Mobile Apps, APIs	Lokale Domänen-Netzwerke (Intranet)
Token-Typ	SAML Assertion	ID Token (zwingend ein signiertes JWT)	Kerberos Tickets (TGT / Service Ticket)
Kryptografie	XML-Schnittstellen-Signaturen (XMLDSIG)	JSON Web Signatures (JWS)	Symmetrische Kryptografie (Secret Keys)
Entwickler-Komplexität	Hoch (Komplexes Parsing von XML-Strukturen)	Niedrig (Einfache Integration in Web-Frameworks)	Hoch (Erfordert tiefe OS- und Domänenintegration)

Die Kehrseite der Medaille: Das Single-Point-of-Compromise-Risiko

Obwohl Single Sign-On erhebliche administrative und benutzerfreundliche Vorteile bietet, müssen IT-Sicherheitsarchitekten ein inhärentes, gravierendes Risiko der Technologie stringent mitigieren. Man spricht hierbei vom Single Point of Failure oder spezifisch im Identitätskontext vom Single Point of Compromise.

In einer traditionellen IT-Landschaft ohne SSO bedeutete der Diebstahl eines Passworts, dass ein Angreifer Zugriff auf genau eine einzige, isolierte Anwendung erlangte. Bei einer flächendeckend implementierten SSO-Architektur hingegen hebt der Kompromiss des primären Benutzerkontos am Identity Provider den Schutzwall für alle angebundenen Systeme gleichzeitig auf. Erlangen Cyberkriminelle über Phishing oder Session-Hijacking (Diebstahl des zentralen IdP-Session-Cookies) Zugriff auf das IdP-Konto des Nutzers, können sie sich ungehindert und unbemerkt lateral durch die gesamte digitale Infrastruktur des Unternehmens bewegen.

Aus diesem Grund darf Single Sign-On unter keinen Umständen als isolierte Sicherheitsmaßnahme betrachtet werden. Der Betrieb einer SSO-Infrastruktur erfordert zwingend die Kopplung mit zwei komplementären Sicherheitsarchitekturen:

• Phishing-resistente Mehrfaktor-Authentifizierung (MFA): Die Anmeldung am Identity Provider darf niemals ausschließlich über ein statisches Passwort geschützt sein. Die Erzwingung moderner MFA-Verfahren, idealerweise basierend auf dem FIDO2/WebAuthn-Standard (z. B. Hardware-Sicherheits-Schlüssel oder Passkeys), ist zwingende Voraussetzung.
• Conditional Access Systeme (Kontextbasierter Zugriff): Der IdP muss vor jeder SSO-Freigabe dynamische Signale in Echtzeit auswerten. Greift der Nutzer von einem unbekannten Standort, zu einer unnatürlichen Zeit oder von einem nicht vom MDM verwalteten, potenziell infizierten Endgerät zu, muss das SSO-Token blockiert oder eine erneute, schärfere Überprüfung erzwungen werden.

Regulatorische Verpflichtungen, NIS2 und BSI IT-Grundschutz

Die Konsolidierung und der Schutz von Benutzeridentitäten über standardisierte Verfahren wie SSO hat im aktuellen europäischen Rechtsraum den Status einer rein empfohlenen Best-Practice längst verlassen. Unter den verschärften Bedingungen der europäischen NIS2-Richtlinie, die im Jahr 2026 vollumfänglich durchgesetzt und kontrolliert wird, sind Organisationen in wichtigen und kritischen Sektoren gesetzlich verpflichtet, Maßnahmen zur Sicherung des Identitäts- und Zugriffmanagements umzusetzen, die dem aktuellen Stand der Technik entsprechen.

Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) definiert im nationalen IT-Grundschutz-Kompendium unmissverständliche Kernkriterien für die Identitätsverwaltung. Die detaillierten Bausteine und Umsetzungshinweise sind über das offizielle Portal der Bundesbehörde abrufbar.

Der spezifische Baustein ORP.4 (Identitäts- und Berechtigungsmanagement) adressiert die Notwendigkeit zentralisierter Authentifizierungsstrukturen explizit. Der IT-Grundschutz fordert im Rahmen der Standard-Sicherheitsanforderungen:

• Dass Benutzeridentitäten über ihren gesamten Lebenszyklus hinweg zentral verwaltet und auditiert werden müssen (ORP.4.A2).
• Dass die Anzahl der vom Benutzer zu merkenden Passwörter durch den Einsatz von Single-Sign-On-Verfahren systematisch zu reduzieren ist, um die Qualität der verbleibenden Primärpasswörter zu erhöhen (ORP.4.A8).
• Dass beim Ausscheiden eines Mitarbeiters alle Zugriffsrechte unverzüglich und zentral entzogen werden müssen – eine Anforderung, die ohne ein zentrales SSO-System im Cloud-Zeitalter praktisch nicht fehlerfrei umsetzbar ist, da das Deaktivieren des Hauptkontos am IdP sofort alle Zugänge zu den angebundenen Service Providern kappt.

Fazit

Single Sign-On (SSO) ist das unumstößliche, infrastrukturelle Fundament für ein sicheres und effizientes Identitätsmanagement im Cloud-Zeitalter. Es löst den historischen Widerspruch zwischen maximaler Benutzereffizienz und kompromissloser IT-Sicherheit auf, indem es das Passwort-Management an einer einzigen, hochgesicherten Stelle konzentriert.

Der wirtschaftliche und sicherheitstechnische Erfolg hängt dabei untrennbar von der Konzeptionsqualität ab – von der Auswahl des passenden Protokolls (wie OIDC für moderne Web-Umgebungen) über die strikte Durchsetzung von FIDO2-basierter Mehrfaktor-Authentifizierung bis hin zur revisionssicheren Einhaltung der BSI IT-Grundschutz-Kriterien und der NIS2-Vorgaben. Wer diese Mechanismen ganzheitlich beherrscht und das Risiko des Single Point of Compromise durch dynamische Conditional-Access-Richtlinien wirksam eindämmt, schafft eine hochresiliente, gesetzeskonforme und zukunftssichere digitale Wertschöpfungskette für das gesamte Unternehmen.