Single Sign-On

Single Sign-On (SSO) ist ein Authentifizierungsverfahren, bei dem sich ein Nutzer einmal an einem zentralen Identity Provider (IdP) anmeldet und anschließend ohne erneute Passworteingabe auf alle angebundenen Anwendungen zugreifen kann. Die einzelnen Dienste — sogenannte Service Provider oder Relying Parties — vertrauen dem IdP und akzeptieren dessen Aussagen über die Identität des Nutzers in Form signierter Tokens oder Assertions. SSO ersetzt damit das Modell, bei dem jede Anwendung eine eigene Benutzerdatenbank und ein eigenes Passwort pflegt, durch eine zentrale, kryptografisch abgesicherte Identitätsschicht.

Wie SSO technisch funktioniert

Im Kern beruht SSO auf einem Vertrauensverhältnis zwischen dem IdP und den angebundenen Anwendungen. Ruft ein Nutzer eine geschützte Anwendung auf, leitet diese den Browser zum IdP um. Dort meldet sich der Nutzer einmalig an — bei modernen Umgebungen typischerweise mit Passwort plus zweitem Faktor. Der IdP stellt anschließend ein signiertes Artefakt aus: eine SAML-Assertion, ein OIDC-ID-Token oder ein Kerberos-Ticket. Dieses Artefakt wird an die Anwendung übergeben, die die Signatur gegen das öffentliche Zertifikat des IdP prüft und die enthaltenen Claims (Nutzername, Gruppen, Attribute) auswertet. Für die Dauer der IdP-Session erkennt der IdP den Nutzer am Sitzungs-Cookie wieder und stellt für weitere Anwendungen neue Tokens aus, ohne erneut nach Anmeldedaten zu fragen.

Die wichtigsten SSO-Protokolle

In der Praxis dominieren drei Protokollfamilien — jede mit eigenen Stärken und Einsatzgebieten.

In der Praxis koexistieren diese Protokolle in der gleichen Umgebung: Kerberos für die interne Domänenanmeldung am Windows-Client, SAML für ältere SaaS-Anwendungen wie SAP SuccessFactors oder Salesforce, OIDC für moderne Apps und mobile Clients. Microsoft Entra ID — der Nachfolger von Azure AD — kann alle drei Protokolle als IdP bedienen und ist in mittelständischen Microsoft-365-Umgebungen die mit Abstand häufigste SSO-Zentrale.

SSO im Enterprise-Kontext

Historisch wurde SSO in vielen deutschen Mittelständlern über ADFS (Active Directory Federation Services) realisiert, einen On-Premises-Föderationsdienst, der SAML- und WS-Federation-Assertions auf Basis der lokalen AD-Identitäten ausstellt. Microsoft empfiehlt inzwischen die Ablösung von ADFS durch Entra ID, da Entra ID Conditional Access, risikobasierte Anmeldung, modernes Token-Refresh und eine deutlich kleinere Angriffsfläche bietet. Wir finden in Assessments dennoch regelmäßig produktive ADFS-Farmen, die Tokens für dutzende Anwendungen ausstellen — oft mit veralteten Zertifikaten und ohne aktive Token-Signaturschlüssel-Rotation. Ein kompromittierter ADFS-Server bedeutet praktisch die vollständige Übernahme aller föderierten Anwendungen, da der Angreifer beliebige Tokens für beliebige Nutzer signieren kann (Golden-SAML-Angriff).

Neben dem zentralen IdP gehört zu einer SSO-Architektur immer ein User-Provisioning-Prozess. SCIM (System for Cross-domain Identity Management) automatisiert das Anlegen, Aktualisieren und Deaktivieren von Konten in den angebundenen Anwendungen, sobald der Nutzer im IdP angelegt oder deaktiviert wird. Ohne SCIM bleibt der Joiner-Mover-Leaver-Prozess fragmentiert und ehemalige Mitarbeiter behalten oft Zugriff auf SaaS-Anwendungen, obwohl das AD-Konto längst gesperrt ist.

Sicherheits-Tradeoffs

SSO bündelt das Risiko: Ein kompromittiertes IdP-Konto öffnet potenziell alle angebundenen Anwendungen gleichzeitig. Diese Konzentration ist jedoch zugleich die größte Stärke des Modells, denn sie erlaubt es, Schutzmaßnahmen einmal zentral durchzusetzen statt in jeder Anwendung einzeln. MFA, Conditional Access, Geräte-Compliance, Risikobewertung, Session-Lifetime und Audit-Logging werden im IdP konfiguriert und gelten automatisch für alle angebundenen Dienste. Ein Angreifer mit gestohlenem Passwort scheitert an der zentralen MFA-Hürde — sofern diese tatsächlich für alle Konten aktiv und phishing-resistent ist.

Damit gilt: SSO ohne starke MFA ist ein Sicherheitsrisiko, kein Sicherheitsgewinn. Ein einziger kompromittierter Login öffnet sonst nicht eine, sondern alle Anwendungen gleichzeitig. In der Praxis bedeutet das die konsequente Aktivierung von FIDO2-Passkeys oder Hardware-Token für alle Nutzer, nicht nur für Administratoren. Ergänzend sollten Token-Lebenszeiten kurz gehalten, Refresh-Tokens an Geräte-Compliance gebunden und privilegierte Anmeldungen separat überwacht werden. Die Signaturschlüssel des IdP — bei ADFS der Token-Signing-Schlüssel, bei Entra ID die Schlüssel im Backend — sind die Kronjuwelen der gesamten Architektur und gehören in ein HSM oder den von Microsoft verwalteten Schlüsselspeicher.

Audit und Nachvollziehbarkeit

Ein zentraler IdP erzeugt einen einheitlichen Audit-Trail über alle Anmeldungen, was die forensische Aufarbeitung von Vorfällen erheblich vereinfacht. Statt Logs aus dutzenden Anwendungen zu korrelieren, lässt sich die Anmeldehistorie eines verdächtigen Kontos zentral abfragen — inklusive Quell-IP, Gerät, Standort, Risikobewertung und genutzter MFA-Methode. Für IAM-Reviews, NIS-2-Nachweise und ISO-27001-Audits ist diese zentrale Sicht ein erheblicher Vorteil gegenüber dezentralen Anmeldemodellen.

Relevanz für KMUs

Für mittelständische Unternehmen ist SSO heute weniger eine Komfortfunktion als eine Voraussetzung für jede ernsthafte Identitätsstrategie. Wir finden in Assessments regelmäßig Umgebungen, in denen Mitarbeiter sich Passwörter für zwanzig oder mehr SaaS-Anwendungen merken müssen — mit absehbar schlechten Passwortgewohnheiten, fehlender MFA in den einzelnen Diensten und einem ungeordneten Offboarding-Prozess. Die Konsolidierung dieser Anwendungen hinter Entra ID oder einem vergleichbaren IdP ist in der Regel mit überschaubarem Aufwand möglich, da praktisch alle relevanten Business-SaaS-Anwendungen SAML oder OIDC unterstützen. Wichtig ist, die Einführung von SSO nie ohne zeitgleiche Härtung der zentralen Anmeldung durchzuführen: phishing-resistente MFA für alle Konten, Conditional Access mit Geräte- und Standortbedingungen, Notfall-Glass-Break-Konten mit Hardware-Token und ein automatisiertes Offboarding über SCIM. Ohne diese Maßnahmen verschiebt SSO das Risiko lediglich an eine einzige, dann umso attraktivere Stelle.