Single Sign-on (SSO)
Single Sign-on heißt Einmalanmeldung: ein Login für mehrere Dienste. Wie der Ablauf funktioniert, welche Standards dahinterstecken und wo das Risiko liegt.
Was ist Single Sign-on?
Single Sign-on, kurz SSO, bedeutet Einmalanmeldung. Eine zentrale Stelle prüft die Identität einer Person, und alle angeschlossenen Dienste vertrauen dieser Prüfung. Das Bundesamt für Sicherheit in der Informationstechnik beschreibt es so: „Single-Sign-On bedeutet übersetzt Einmalanmeldung." Ein Passwort, viele Anwendungen, keine zweite Eingabe.
Wie läuft eine Anmeldung per SSO ab?
In vier Schritten. Die Anwendung, in die jemand möchte, verweist die Anfrage an den zentralen Anmeldedienst, den Identity Provider. Dieser prüft, ob die Person bereits angemeldet ist, und fragt andernfalls nach Passwort und zweitem Faktor. Nach erfolgreicher Prüfung stellt er eine signierte Bestätigung aus. Die Anwendung prüft die Signatur und gewährt den Zugang. Das BSI beschreibt den entscheidenden Schritt so: Die Bestätigung „enthält eine elektronische Signatur, die auf sogenannten asymmetrischen Kryptoalgorithmen basiert", und erst dadurch könne die Anwendung prüfen, ob die Information wirklich vom zentralen Dienst stammt. Das Passwort selbst sieht die Anwendung nie. Genau das ist der Sicherheitsgewinn, und er wird oft übersehen: SSO verringert nicht nur die Zahl der Anmeldungen, sondern auch die Zahl der Orte, an denen ein Passwort liegen könnte.
Welche Standards stecken hinter SSO?
Drei Protokolle decken praktisch den gesamten Markt ab. SAML 2.0 wurde nach der Übersicht in der englischsprachigen Wikipedia im März 2005 als OASIS-Standard verabschiedet und ist in klassischen Unternehmensumgebungen verbreitet. OAuth 2.0 regelt die Autorisierung, also den delegierten Zugriff, und wurde von der IETF im Oktober 2012 als RFC 6749 veröffentlicht; der Text beschreibt ein Verfahren, das „enables a third-party application to obtain limited access to an HTTP service". OpenID Connect ist die Identitätsschicht darüber und liefert die Aussage, wer sich angemeldet hat.
Der Unterschied zwischen den beiden letzten ist die häufigste Verwechslung im Beschaffungsgespräch. OAuth beantwortet die Frage, was eine Anwendung darf. OpenID Connect beantwortet die Frage, wer da ist. Wer nur OAuth einkauft und Anmeldung erwartet, kauft die halbe Sache.
Warum kann Single Sign-on die Sicherheit gefährden?
Weil alles an einem Konto hängt. Das BSI benennt das Risiko ohne Umschweife: „Risiko Nr. 1: Ist der zentrale Account geknackt, sind alle Accounts geknackt." Wer Zugang zum zentralen Konto hat, kommt auch in alle angeschlossenen Dienste.
Daraus folgen drei Anforderungen, die zu jedem SSO gehören. Ein zweiter Faktor am zentralen Konto, möglichst phishing-resistent. Eine Sitzungsdauer, die zum Gerät passt, denn eine Anmeldung, die auf einem gemeinsam genutzten Tablet in der Werkstatt tagelang gilt, ist keine Anmeldung mehr. Und ein Abmeldeweg, der wirklich alle Sitzungen beendet, nicht nur die im aktuellen Browserfenster.
Die Gegenrechnung fällt trotzdem klar aus. Die US-Behörde NIST schreibt in SP 800-63B: „The overarching authentication usability goal is to minimize user burden and authentication friction … Single sign-on exemplifies one such minimization strategy." Weniger Anmeldungen bedeuten weniger notierte Passwörter, und der Zugriffsentzug beim Austritt wird zu einer einzigen Handlung statt zu einer Liste.
Was ist der Unterschied zwischen SSO und SAML?
SSO ist das Ziel, SAML ein Weg dorthin. Single Sign-on beschreibt, was die Nutzerin erlebt: einmal anmelden, überall drin sein. SAML ist eines der Formate, in denen der zentrale Anmeldedienst und die Anwendung ihre Nachrichten austauschen. Dasselbe Erlebnis lässt sich auch mit OpenID Connect herstellen. Ein Anbieter, der „SSO" auf die Preisliste schreibt, hat damit noch nicht gesagt, welches Protokoll er unterstützt, und genau danach sollte man fragen.
Wen erreicht Single Sign-on nicht?
Alle, die kein Konto im Verzeichnis haben. SSO setzt eine Identität voraus, meist gebunden an eine Firmen-E-Mail-Adresse, und in Produktion, Pflege und Logistik fehlt genau die häufig. In Deutschland hatten 2025 nach Daten von Eurostat 68,4 % der Beschäftigten in Betrieben ab zehn Personen einen Internetzugang für die Arbeit; im Verarbeitenden Gewerbe waren es 64,1 %, im Baugewerbe 60,6 %, in Verkehr und Lagerei 61,3 % und in der Herstellung von Nahrungsmitteln, Getränken und Tabak 39,2 %. Im Durchschnitt der EU27 lag der Wert bei 64,6 %. Die Erhebung erfasst Betriebe ab zehn Beschäftigten und lässt Land- und Forstwirtschaft, Bergbau sowie den Finanzsektor aus. Für diese Gruppe löst SSO nichts, weil es das Problem am falschen Ende anfasst: Es vereinfacht die Anmeldung für Menschen, die bereits ein Konto haben. Wer die gesamte Belegschaft erreichen will, braucht daneben einen zweiten Anmeldeweg, der ohne Firmen-E-Mail-Adresse auskommt, etwa einen Zugangscode. Beide Wege in dieselbe Anwendung zu führen ist die Arbeit, die dabei anfällt, und sie fällt genau einmal an.
Wie unterstützt tchop Single Sign-on?
tchop bindet bestehende Anmeldedienste an und lässt daneben den Zugang ohne Firmenkonto zu. Verwaltungs- und Bürobelegschaft meldet sich über den zentralen Anmeldedienst des Unternehmens an, die Produktion über einen Zugangscode, und beide landen in derselben App unter dem Namen des Unternehmens. Bei der AOK PLUS melden sich die Beschäftigten mit ihren vorhandenen Zugangsdaten über das Single Sign-on der AOK an, ein zweites Konto braucht niemand. Eine Grenze gehört dazu: tchop ist kein Identity Provider und verwaltet keine Identitäten für andere Systeme.
Mehr dazu auf der Sicherheitsseite von tchop.
FAQs: Single Sign-on
Wie funktioniert Single Sign-on einfach erklärt?
Statt sich bei jeder Anwendung einzeln anzumelden, melden Sie sich einmal bei einer zentralen Stelle an. Diese stellt eine signierte Bestätigung aus, die jede angeschlossene Anwendung prüfen kann. Ihr Passwort bekommt die Anwendung nicht zu sehen; sie sieht nur die Bestätigung, dass die Prüfung stattgefunden hat.
Was ist der Unterschied zwischen SSO und einem Passwortmanager?
Der Passwortmanager speichert viele Passwörter und füllt sie für Sie aus. Bei SSO gibt es die anderen Passwörter gar nicht: Die Anwendungen haben keine eigenen Anmeldedaten, sondern vertrauen dem zentralen Dienst. Der Passwortmanager verwaltet das Problem, SSO schafft es ab.
Ist ein Google- oder Microsoft-Konto ein SSO?
Ja, das ist genau der Fall, den die meisten kennen. Wer sich auf einer Website „mit Google fortfahren" anmeldet, nutzt Single Sign-on mit Google als zentralem Anmeldedienst. Im Unternehmen ist das Prinzip dasselbe, nur ist der zentrale Dienst dann das Verzeichnis des Arbeitgebers.
Braucht SSO eine Betriebsvereinbarung?
Häufig ja, denn ein zentraler Anmeldedienst protokolliert, wer sich wann bei welcher Anwendung angemeldet hat. Damit fällt er unter § 87 Abs. 1 Nr. 6 BetrVG, das Mitbestimmungsrecht bei technischen Einrichtungen, die Verhalten oder Leistung erfassen können. Geregelt werden sollte, welche Protokolle anfallen, wie lange sie aufbewahrt und von wem sie ausgewertet werden.
Quellen
Bundesamt für Sicherheit in der Informationstechnik, „Single-Sign-On", abgerufen am 23. September 2026
IETF, RFC 6749 „The OAuth 2.0 Authorization Framework", Oktober 2012
NIST Special Publication 800-63B, „Digital Identity Guidelines: Authentication and Lifecycle Management"
Eurostat, Datensatz
isoc_ci_cm_pn2, Deutschland 2025, Datenstand 15. Juni 2026Betriebsverfassungsgesetz, § 87 Abs. 1 Nr. 6
