Single Sign-On (SSO)

Single Sign-On (SSO) bezeichnet ein Anmeldeverfahren, bei dem sich Nutzer einmal bei einer zentralen Stelle authentifizieren und danach auf mehrere Anwendungen zugreifen können, ohne sich erneut anzumelden. Die zentrale Stelle heißt Identity Provider (IdP). Die Anwendungen, die ihr vertrauen, heißen Service Provider oder, in der OpenID-Terminologie, Relying Parties.

Für Anwender heißt das: ein Login am Morgen, danach Zugriff auf E-Mail, Zeiterfassung, Warenwirtschaft und Shop-Backend. Für IT und Geschäftsführung heißt es: eine Stelle, an der Konten angelegt, abgesichert und beim Austritt gesperrt werden. Genau diese zentrale Kontrolle ist im Unternehmensumfeld der eigentliche Nutzen, nicht die gesparte Passworteingabe.

Wie Single Sign-On funktioniert

Das Grundprinzip ist bei allen gängigen Verfahren gleich. Ruft ein Nutzer eine Anwendung auf, ohne angemeldet zu sein, leitet diese ihn an den Identity Provider weiter. Der IdP prüft die Identität, etwa per Passwort und zweitem Faktor, und schickt eine signierte Bestätigung an die Anwendung zurück. Die Anwendung vertraut der Signatur, legt eine eigene Sitzung an und lässt den Nutzer herein. Beim nächsten Dienst erkennt der IdP die bestehende Sitzung und stellt die Bestätigung ohne erneute Eingabe aus.

Die Anwendung sieht das Passwort des Nutzers dabei nie. Sie erhält nur eine Aussage des Identity Providers, wer sich angemeldet hat, häufig zusammen mit Attributen wie E-Mail-Adresse, Name, Abteilung oder Gruppenzugehörigkeit. Das ist sicherheitlich ein Gewinn, weil Zugangsdaten nur an einer Stelle liegen und dort professionell geschützt werden können.

Die wichtigsten Protokolle

SAML 2.0 ist der Klassiker im Unternehmensbereich. Der Identity Provider stellt eine XML-Assertion aus, die digital signiert ist, und übergibt sie über den Browser an die Anwendung. Das Verfahren ist ausgereift und weit verbreitet, wirkt aber im Vergleich schwergewichtig, weil XML-Signaturen und Metadaten-Austausch Sorgfalt verlangen.

OpenID Connect ist eine Identitätsschicht auf OAuth 2.0. OAuth 2.0 selbst (RFC 6749) regelt die Autorisierung, also den delegierten Zugriff auf Ressourcen. OIDC ergänzt darum ein ID-Token im JWT-Format, das aussagt, wer der Nutzer ist. Für Webanwendungen ist der Authorization-Code-Flow üblich, für öffentliche Clients wie Apps und Single-Page-Anwendungen zusätzlich mit PKCE. OIDC gilt als leichter zu implementieren als SAML und hat sich bei neuen Projekten weitgehend durchgesetzt.

Abgrenzung: SSO, Authentifizierung, Autorisierung

Drei Begriffe werden im Alltag häufig vermischt. Authentifizierung klärt, wer jemand ist. Autorisierung klärt, was diese Person darf. Single Sign-On ist ein Verfahren, mit dem sich die Authentifizierung für mehrere Anwendungen bündeln lässt. SSO sagt noch nichts darüber aus, welche Rechte der Nutzer in der jeweiligen Anwendung hat. Diese Zuordnung übernimmt in der Regel ein rollenbasiertes Berechtigungsmodell, das Gruppen oder Rollen aus dem Identity Provider auf Anwendungsrechte abbildet.

Ebenfalls zu unterscheiden ist SSO vom Passwortmanager. Ein Passwortmanager speichert viele Zugangsdaten und füllt sie aus, die Anwendungen prüfen aber weiterhin eigene Passwörter. Bei echtem SSO gibt es nur noch eine Anmeldung, und die Anwendungen kennen kein Passwort mehr. Auch der Social Login („Mit Google anmelden“) ist technisch ein SSO-Verfahren, meist über OIDC, mit dem Unterschied, dass der Identity Provider ein Konsumentendienst ist und kein Unternehmensverzeichnis.

Warum SSO im Unternehmen und im E-Commerce relevant ist

Ein Onlinehändler oder Hersteller arbeitet typischerweise mit einem Dutzend Systemen: Shop-Backend, ERP, PIM, CRM, Ticketsystem, Analytics, E-Mail-Marketing, Zahlungsanbieter-Portal. Ohne zentrale Anmeldung führt jedes System eigene Konten mit eigenen Passwörtern. Das erzeugt vorhersehbare Probleme.

• Offboarding-Lücken: Verlässt jemand das Unternehmen, müssen zwölf Konten einzeln gesperrt werden. Vergessene Konten bleiben als Einfallstor offen.
• Passwortmüdigkeit: Wer zwölf Passwörter braucht, wählt schwache oder wiederverwendet sie. Die Folge sind Credential-Stuffing-Angriffe, bei denen gestohlene Zugangsdaten aus einem Dienst bei anderen ausprobiert werden.
• Uneinheitliche Absicherung: Nicht jede Anwendung bietet Mehrfaktor-Authentifizierung. Mit SSO wird der zweite Faktor einmal am Identity Provider erzwungen und gilt für alles dahinter.
• Fehlende Nachvollziehbarkeit: Anmeldungen an einer zentralen Stelle lassen sich protokollieren und auswerten, statt in zwölf getrennten Logs zu verschwinden.
• Support-Aufwand: Passwort-Resets gehören zu den häufigsten Helpdesk-Anfragen. Zentrale Anmeldung reduziert sie.

Für Regulierung und Zertifizierung ist das ebenfalls relevant. Anforderungen aus ISO/IEC 27001, aus der NIS-2-Richtlinie oder aus Kundenaudits laufen im Kern auf nachweisbare Zugriffskontrolle hinaus. Ein Identity Provider mit erzwungener Mehrfaktor-Authentifizierung und zentraler Sperrung liefert die Belege dafür in einer Form, die Auditoren nachvollziehen können.

SSO im Shop-Backend

Commerce-Backends müssen sich in dieses Bild einfügen. Wer ein Shopsystem im Mittelstand einführt, stellt die Frage nach der Firmenanmeldung meist im Lastenheft: Melden sich Mitarbeitende mit ihrem Unternehmenskonto an? Wird das Konto beim Austritt automatisch gesperrt? Können Gruppen aus dem Verzeichnisdienst auf Rollen im Shop abgebildet werden?

Die Antworten unterscheiden sich stark zwischen Plattformen. Bei manchen ist SSO Teil der Standardinstallation oder über Erweiterungen erhältlich, bei anderen ausschließlich in kommerziellen Editionen. Ein aktuelles Beispiel ist MedusaJS: Laut der ENTERPRISE-LICENSE.md im Repository fällt die Anbindung ans Firmen-Identity-Management über den OIDC-Auth-Provider seit August 2026 unter die Enterprise-Lizenz, während generische Authentifizierung und die normale Nutzerverwaltung unter MIT bleiben. Die Einordnung findest du im Beitrag zu MedusaJS und im Eintrag zum Open-Core-Modell.

Ein Beispiel: Anmeldung per OpenID Connect

Ein typischer OIDC-Ablauf mit Authorization-Code-Flow lässt sich in wenigen Schritten beschreiben:

1. Der Nutzer ruft das Shop-Backend auf. Es besteht keine Sitzung.
2. Das Backend leitet den Browser zum Identity Provider weiter, zum Beispiel Microsoft Entra ID, Okta oder Keycloak, und übergibt Client-ID, Redirect-URI, Scopes wie openid und email sowie einen Zufallswert zum Schutz gegen Manipulation.
3. Der Identity Provider authentifiziert den Nutzer, gegebenenfalls mit zweitem Faktor.
4. Er leitet den Browser mit einem einmaligen Autorisierungscode zurück zum Backend.
5. Das Backend tauscht den Code auf direktem Serverweg gegen ein ID-Token und ein Access-Token.
6. Es prüft die Signatur des ID-Tokens, liest Claims wie email oder groups aus und legt eine eigene Sitzung an.

Wichtig ist Schritt 5: Der Austausch des Codes erfolgt zwischen Server und Identity Provider, nicht im Browser. Dadurch bleiben die Tokens dem Zugriff durch Skripte im Browser entzogen. Die verbreiteten Identity Provider sind Microsoft Entra ID (früher Azure Active Directory), Okta, Keycloak als Open-Source-Lösung, Google Workspace und Auth0.

Gruppen und Attribute: Was der Identity Provider mitliefert

Neben der reinen Identität transportiert das Token oder die Assertion sogenannte Claims beziehungsweise Attribute. Dazu gehören die E-Mail-Adresse als eindeutiger Bezeichner, der Anzeigename und oft eine Liste von Gruppen. In der Praxis entscheidet die Qualität dieser Zuordnung darüber, ob SSO im Alltag funktioniert. Wird die Gruppe „Vertrieb“ im Verzeichnis auf die Rolle „Preisverwaltung“ im Shop abgebildet, erhalten neue Mitarbeitende beim ersten Login automatisch die passenden Rechte. Bleibt die Zuordnung unklar, landen alle Nutzer mit Standardrechten im System und müssen nachträglich von Hand berechtigt werden, was den Vorteil der zentralen Steuerung wieder aufhebt.

Zwei Regeln haben sich dabei bewährt. Erstens sollte der eindeutige Schlüssel eines Kontos eine stabile Kennung sein und keine E-Mail-Adresse, die sich ändern kann, etwa bei Namenswechsel oder Umzug in eine andere Domäne. Zweitens sollte die Anwendung Gruppenzugehörigkeiten bei jeder Anmeldung neu auswerten und nicht einmalig beim Anlegen des Kontos speichern, damit Änderungen im Verzeichnis zeitnah durchschlagen.

Risiken und Grenzen

Zentraler Ausfallpunkt. Fällt der Identity Provider aus, kommt niemand mehr in die angeschlossenen Anwendungen. Verfügbarkeit und Notfallzugänge (Break-Glass-Konten) müssen deshalb bewusst geplant werden.

Größerer Schaden bei Kompromittierung. Ein gestohlenes Konto öffnet potenziell alle angeschlossenen Systeme. Das ist der Grund, warum SSO ohne Mehrfaktor-Authentifizierung wenig sinnvoll ist. Der Komfortgewinn darf nicht auf Kosten der Absicherung gehen.

Falsch konfigurierte Vertrauensbeziehungen. Typische Fehler sind zu weit gefasste Redirect-URIs, nicht geprüfte Signaturen oder fehlende Validierung von Zielgruppe und Aussteller im Token. Solche Konfigurationsfehler gehören zu den häufigsten Ursachen für Sicherheitslücken in SSO-Integrationen.

Sitzungsende ist nicht gleich Abmeldung. Meldet sich ein Nutzer bei einer Anwendung ab, bleibt seine Sitzung am Identity Provider oft bestehen. Ein vollständiges Single Logout ist technisch anspruchsvoll und wird nicht von allen Anwendungen zuverlässig unterstützt.

Lizenzkosten. SSO-Funktionen werden in Software häufig als Aufpreis-Merkmal geführt. Das gilt so verbreitet, dass sich der Begriff „SSO Tax“ für den Preisaufschlag eingebürgert hat, den Hersteller für die Firmenanmeldung verlangen. Wer Software einkauft, sollte diesen Punkt vor der Entscheidung klären.

Bereitstellung von Konten: SCIM

SSO regelt die Anmeldung, nicht das Anlegen und Löschen von Konten. Für diesen Teil gibt es den Standard SCIM (System for Cross-domain Identity Management, RFC 7643 und 7644). Damit kann ein Identity Provider Nutzerkonten in angeschlossenen Anwendungen automatisch anlegen, ändern und deaktivieren. Erst die Kombination aus SSO und SCIM löst das Offboarding-Problem wirklich: Wird das Konto im Verzeichnis deaktiviert, verschwindet der Zugang überall, ohne dass jemand Anwendungen einzeln abklappert.

Ausblick

Passwörter verlieren an Bedeutung. Passkeys auf Basis von FIDO2 und WebAuthn ersetzen Passwörter durch kryptografische Schlüsselpaare, die das Gerät des Nutzers verwaltet. Identity Provider unterstützen sie zunehmend als Anmeldeweg, sodass SSO und passwortlose Authentifizierung zusammenwachsen. Gleichzeitig wandert die Prüfung von einer einmaligen Anmeldung zu einer laufenden Bewertung von Gerät, Standort und Verhalten, wie sie Zero-Trust-Architekturen vorsehen. Für Anwendungen bedeutet das, dass eine Anmeldung nicht mehr als dauerhafter Freibrief gilt.

Für den Mittelstand bleibt die Praxisregel einfach: Sobald mehr als eine Handvoll Anwendungen und mehr als eine Handvoll Nutzer zusammenkommen, spart ein zentraler Identity Provider mehr Aufwand, als er kostet, und er verbessert die Sicherheit messbar.

Häufige Fragen zu Single Sign-On

Was ist der Unterschied zwischen SSO, SAML und OIDC?

SSO ist das Ziel, eine Anmeldung für mehrere Anwendungen. SAML und OpenID Connect sind Protokolle, mit denen dieses Ziel technisch umgesetzt wird. SAML basiert auf XML und ist im Unternehmensumfeld verbreitet, OIDC basiert auf JSON und OAuth 2.0 und ist bei neueren Anwendungen üblich.

Ist SSO sicherer als einzelne Passwörter?

In der Regel ja, wenn der Identity Provider gut abgesichert ist und Mehrfaktor-Authentifizierung erzwingt. Zugangsdaten liegen an einer Stelle, Sperrungen wirken überall. Ohne zweiten Faktor konzentriert sich das Risiko allerdings auf ein einziges Konto.

Braucht ein kleines Unternehmen SSO?

Bei wenigen Nutzern und Systemen nicht zwingend. Sobald mehrere Abteilungen, externe Dienstleister oder Compliance-Anforderungen hinzukommen, lohnt sich die Einführung.

Ersetzt SSO die Rechteverwaltung?

Nein. SSO klärt, wer sich anmeldet. Was die Person in der Anwendung darf, regelt ein separates Berechtigungsmodell, meist auf Basis von Rollen.

Was ist Social Login?

Social Login erlaubt die Anmeldung mit einem bestehenden Konto bei einem großen Anbieter wie Google oder Apple. Technisch ist es ein SSO-Verfahren auf OIDC-Basis, das im Endkundengeschäft eingesetzt wird und nicht für Unternehmensverzeichnisse gedacht ist.

Weiterführende Quellen

Die Spezifikation von OpenID Connect ist bei der OpenID Foundation veröffentlicht. Den zugrunde liegenden Autorisierungsstandard beschreibt RFC 6749 (OAuth 2.0). Einen Überblick über das Konzept gibt der Wikipedia-Artikel zu Single Sign-on.