Was ist Single Sign-On (SSO)?

Was ist Single Sign-On (SSO)?

Single Sign-On (SSO) ist ein Authentifizierungsschema, bei dem sich ein Nutzer einmal mit einem einzigen Satz Credentials anmeldet und Zugriff auf mehrere verbundene Anwendungen erhält, ohne sich erneut einloggen zu müssen. Im Hintergrund verifiziert ein Identity Provider (IdP) — Okta, Microsoft Entra ID, Google Workspace, Auth0 — den Nutzer, und ein Service Provider (SP) — Slack, Salesforce, GitHub, deine interne App — akzeptiert das Verifizierungs-Token des IdP statt nach einem Passwort zu fragen.

SSO dominiert im Enterprise-Bereich: Ein typischer Mitarbeiter berührt 10–30 SaaS-Apps am Tag, und sie sich bei jeder einzeln anmelden zu lassen, ist eine Produktivitätskatastrophe + eine Password-Reuse-Sicherheitskatastrophe. Mit SSO meldet sich der Nutzer einmal zu Beginn des Arbeitstages beim IdP an; jede verbundene App akzeptiert diese Authentifizierung für den Rest der Sitzung.

Wie SSO tatsächlich funktioniert

Der grobe Ablauf ist über die Protokolle hinweg derselbe, auch wenn die Implementierungsdetails sich unterscheiden:

1. Nutzer klickt auf "Anmelden" beim SP (der App, die er nutzen will).
2. SP leitet den Nutzer zum IdP weiter mit der Anfrage: "bitte authentifiziere diesen Nutzer für mich".
3. IdP authentifiziert den Nutzer — prüft Credentials, kann auch MFA, Conditional-Access-Policies ("nur auf verwalteten Geräten"), Session-Limits durchsetzen.
4. IdP stellt ein Token aus — eine kryptografisch signierte Assertion, die sagt "dieser Nutzer ist authentifiziert, und hier ist seine Identität (E-Mail, Name, Gruppenmitgliedschaften)".
5. IdP leitet den Nutzer mit dem Token zurück zum SP.
6. SP validiert die Signatur des Tokens mit dem öffentlichen Schlüssel des IdP und vertraut darauf, dass der Nutzer der ist, den der IdP angibt. SP erstellt eine lokale Sitzung.

Der Nutzer erlebt das üblicherweise als einen einzelnen Browser-Redirect — er klickt auf "Mit Okta anmelden", sieht kurz die IdP-Seite (oder nicht, wenn er bereits angemeldet ist) und landet bereits authentifiziert wieder in der App. Verstrichene Gesamtzeit: 1–2 Sekunden.

Die 3 wichtigsten SSO-Protokolle (SAML, OIDC, OAuth)

SAML 2.0

Der Großvater des Enterprise-SSO, 2005 ratifiziert. SAML nutzt XML-formatierte Assertions, die zwischen IdP und SP ausgetauscht und mit X.509-Zertifikaten signiert werden. Es ist verbose, komplex zu debuggen (mehrzeilige base64-codierte XML in URL-Parametern oder POST-Bodies), aber felsenfest und im Enterprise allgegenwärtig. Wenn eine SaaS-App sagt "SSO unterstützt", meint sie fast sicher SAML 2.0. Slack, Salesforce, AWS, Workday — alle SAML.

OpenID Connect (OIDC)

Der moderne Nachfolger, aufgebaut auf OAuth 2.0 und JSON Web Tokens (JWTs). OIDC treibt "Mit Google anmelden", "Mit Apple anmelden", "Mit Microsoft anmelden" an. JSON-basiert, einfacher zu implementieren, in modernen Auth-Bibliotheken gut unterstützt. Neuere SaaS-Produkte starten mit OIDC und fügen SAML später für Enterprise-Kunden hinzu, die darauf bestehen.

OAuth 2.0 (technisch kein SSO)

OAuth ist ein Autorisierungs-Framework — "darf diese App auf die Daten dieses Nutzers zugreifen?" — kein striktes Authentifizierungs-Framework. Aber es wird häufig mit SSO verwechselt, weil derselbe redirect-basierte Flow genutzt wird. "Mit GitHub anmelden" nutzt OAuth: Die App bekommt ein Token, um GitHubs API als der Nutzer aufzurufen, und leitet die Identität daraus ab. OIDC fügt standardisierte Identitäts-Claims über OAuth hinzu, was es zu echtem SSO macht.

Service-Provider-initiiert vs. Identity-Provider-initiiert

SSO-Logins starten an einer von zwei Stellen:

• SP-initiiert: Nutzer geht zuerst zu https://app.example.com, klickt auf Anmelden, wird zum IdP weitergeleitet, kommt zurück. Das ist die überwiegende Mehrheit der Real-World-Flows.
• IdP-initiiert: Nutzer startet im App-Launcher des IdP (z.B. Okta-Dashboard), klickt auf das SP-Tile. Der IdP generiert eine unaufgeforderte Assertion und POSTet sie an den SP, der den Nutzer direkt einloggt. Praktisch, aber aus Sicherheitssicht komplexer — ein SP muss Assertions akzeptieren, die er nicht angefordert hat.

Die meisten SAML-SaaS-Apps unterstützen beide. OIDC ist im Design im Wesentlichen nur SP-initiiert.

Warum SSO die Sicherheit verbessert (kontraintuitiv)

Es fühlt sich so an, als ob "ein Login für alles" den Blast-Radius eines gestohlenen Credentials vergrößern müsste. In der Praxis ist das Gegenteil der Fall:

• Zentralisierte MFA-Durchsetzung. MFA über 30 einzelne Apps durchzusetzen ist unmöglich — manche Apps unterstützen es nicht, andere haben schwache Implementierungen. Mit SSO setzt du starke MFA am IdP durch, und jede verbundene App profitiert.
• Ein Ort, um Zugriff zu widerrufen. Wenn ein Mitarbeiter geht, deaktivierst du sein IdP-Konto einmal und er verliert sofort den Zugriff auf jede verbundene App. Ohne SSO würdest du Konten an 30 Stellen löschen (und manche vergessen).
• Kein Password-Reuse mehr. Nutzer mit separaten Passwörtern für 30 Apps recyceln sie. SSO eliminiert das Reuse-Problem an der Quelle — der Nutzer muss nur ein Passwort verwalten.
• Audit-Trail an einem Ort. Login-Aktivität, MFA-Challenges, fehlgeschlagene Versuche — alles in den Logs des IdP sichtbar. Ohne SSO sind Audit-Daten über 30 Anbieter fragmentiert.

Häufige SSO-Gotchas

• Just-in-Time (JIT) Provisioning. Viele SAML-SaaS-Apps erstellen Nutzer-Records beim ersten SSO-Login. Wenn dein IdP Gruppenmitgliedschaften in der Assertion mitsendet, kann der SP auch automatisch Rollen zuweisen. Ohne JIT erstellt ein Admin jeden Nutzer manuell, bevor er sich einloggen kann — okay für kleine Teams, schmerzhaft im Maßstab.
• Gruppen-Claim-Mapping. Der IdP sendet üblicherweise Gruppenmitgliedschaften in der Assertion. Der SP muss diese Gruppen auf lokale Rollen mappen. Falsch konfigurierte Group-Mappings sind die #1-Quelle für "warum bin ich kein Admin?"-Tickets nach einer SSO-Migration.
• Clock-Skew. SAML-Assertions haben NotBefore- und NotOnOrAfter-Gültigkeits-Timestamps. Wenn die Uhren von IdP und SP um mehr als den konfigurierten Skew (üblicherweise 60–300 Sekunden) abweichen, schlägt die Authentifizierung fehl. Alles per NTP synchronisieren.
• Zertifikatsrotation. SAML signiert Assertions mit X.509-Zertifikaten, die ablaufen (üblicherweise alle 1–3 Jahre). Zu vergessen, Certs vor Ablauf zu rotieren, legt SSO um 03:00 Uhr an einem Dienstag lahm. Kalender-Erinnerungen sind Pflicht.
• SP-initiiertes Logout vs. Single Logout. Sich vom SP abzumelden meldet dich nicht zwingend vom IdP oder anderen verbundenen SPs ab. Single Logout (SLO) ist in der Praxis chaotisch und viele Anbieter implementieren es nicht vollständig. Im Enterprise schließen Nutzer oft einfach den Browser.
• Session-Lifetime-Mismatches. Wenn der IdP eine 12-Stunden-Sitzung gibt, aber der SP 1-Stunden-Sitzungen erzwingt, werden Nutzer ständig re-prompted, obwohl sie "bereits angemeldet" sind. Lifetimes sorgfältig abgleichen.

SSO vs. Federated Identity vs. OAuth — was ist was?

Diese drei Begriffe verheddern sich. Schnelle Disambiguierung:

• SSO (Single Sign-On): User-Experience-Muster — ein Login, viele Apps. Sagt nichts darüber, wie es implementiert ist.
• Federated Identity: Die technische Fähigkeit für IdP und SP, einander über Organisationsgrenzen hinweg zu vertrauen. SSO erfordert üblicherweise Federated Identity; Federated Identity kann auch andere Dinge ermöglichen (z.B. User-Attribut-Sharing).
• OAuth 2.0: Ein Autorisierungsprotokoll (Zugriff auf Daten delegieren). Wird als Building-Block für OIDC verwendet, aber für sich allein etabliert es keine Identität.
• OIDC: Eine Authentifizierungsschicht über OAuth. Fügt ein ID-Token mit standardisierten Identitäts-Claims hinzu.

FAQ: Single Sign-On (SSO)

Was ist der Unterschied zwischen SSO und Passwortmanagern?

Ein Passwortmanager speichert separate Credentials für jede App und füllt sie automatisch aus — der Nutzer hat immer noch 30 verschiedene Passwörter, nur automatisch eingegeben. SSO ersetzt die 30 Passwörter durch ein IdP-Login: Jede App vertraut der Verifikation des IdP, kein App-spezifisches Passwort existiert. SSO ist sicherer (kein Password-Reuse möglich), erfordert aber, dass jede App ein SSO-Protokoll unterstützt.

Können kleine Teams SSO ohne Enterprise-Preise nutzen?

Ja — Google Workspace und Microsoft 365 enthalten OIDC SSO für viele SaaS-Apps ohne Aufpreis. Auth0 hat einen kostenlosen Tarif für unter 7.000 Nutzer. Viele Open-Source-IdPs (Keycloak, Authentik) sind kostenlos selbst zu hosten. Die Kostenbarrieren für SSO sind seit 2020 dramatisch gesunken.

Ist SAML noch relevant oder sollte ich einfach OIDC nutzen?

Für neue Integrationen OIDC, wenn beide Seiten es unterstützen — einfacher, JSON-basiert, leichter zu debuggen. Für Enterprise-SaaS ist SAML weiterhin erforderlich, weil die meisten IdPs und die meisten Enterprise-SaaS-Kataloge mit SAML führen. Plane für beides: implementiere OIDC für Self-Service-Signups und SAML für Enterprise-Verträge.

Was ist die SSO Tax?

Die "SSO Tax" ist die Praxis von SaaS-Anbietern, deutlich mehr für SSO-Support zu verlangen — manchmal Kunden zu Enterprise-Stufen zu drängen, nur um SSO zu bekommen. Es gibt Branchen-Pushback (sso.tax trackt Anbieter, die das tun). Manche Anbieter haben reagiert, indem sie SSO in niedrigeren Tarifen einschließen; viele nicht.

Was ist SCIM und wie verhält es sich zu SSO?

SCIM (System for Cross-domain Identity Management) automatisiert User-Provisioning und -Deprovisioning zwischen IdP und SPs. SSO handhabt Authentifizierung; SCIM handhabt "erstelle diesen Nutzer, wenn er zum IdP hinzugefügt wird, lösche ihn, wenn er entfernt wird". Zusammen sind SSO + SCIM der Goldstandard für gemanagte Enterprise-SaaS.

Was passiert mit SSO, wenn der IdP ausfällt?

Nutzer können sich nirgends einloggen. Deshalb ist IdP-Verfügbarkeit kritisch. Die meisten IdPs publizieren 99,99%-SLAs; manche Unternehmen betreiben einen Backup-IdP für Failover. Für super-kritische Apps mindestens einen lokalen Admin-Account behalten, der SSO für Notfall-Zugriff umgeht.

Wie LoadFocus mit SSO integriert

LoadFocus unterstützt SAML 2.0 und OIDC SSO in seinen Enterprise-Plänen. Verbinde deinen IdP (Okta, Microsoft Entra ID, Google Workspace, Auth0) einmal; provisioniere Teammitglieder über die Gruppenmitgliedschaft deines IdP; widerrufe Zugriff zentral, wenn jemand geht. Konfiguriere SSO über deine Account-Einstellungen — Anweisungen pro IdP sind in den Docs.