Single Sign-on (SSO)
Was ist Single Sign-on (SSO)?
Single Sign-on (SSO) ist ein Anmeldeverfahren, bei dem sich ein Nutzer einmal authentifiziert und anschließend auf mehrere verbundene Anwendungen zugreifen kann. Eine zentrale Identitätsstelle bestätigt die Anmeldung gegenüber den beteiligten Diensten. Dadurch sinkt die Zahl separater Logins, während Zugriffsrechte und Sicherheitsregeln zentral verwaltet werden können.
Single Sign-on (SSO), auf Deutsch Einmalanmeldung, verbindet mehrere Anwendungen mit einem zentralen Identitätsdienst. Der Nutzer meldet sich beispielsweise am Unternehmensportal an und kann danach ohne erneute Passworteingabe das CRM, ein Analyse-Dashboard oder ein Redaktionssystem öffnen.
Wie funktioniert Single Sign-on (SSO)?
Single Sign-on (SSO) verteilt das Passwort nicht an alle angeschlossenen Anwendungen. Die Zugangsdaten werden beim Identity Provider geprüft, also bei dem Dienst, der die Identität des Nutzers verwaltet. Die gewünschte Anwendung wird als Service Provider bezeichnet und vertraut auf die vom Identity Provider ausgestellte Bestätigung.
Ein typischer Anmeldevorgang besteht aus fünf Schritten:
Der zentrale Denkfehler bei Single Sign-on (SSO) besteht in der Annahme, dass eine einzige Sitzung automatisch für alle Anwendungen gilt. Tatsächlich erstellt gewöhnlich jede Anwendung eine eigene Sitzung. Die zentrale Anmeldung liefert nur den vertrauenswürdigen Identitätsnachweis. Prüfe deshalb für jede angebundene Anwendung getrennt, wie lange ihre Sitzung gültig bleibt und unter welchen Bedingungen eine erneute Anmeldung verlangt wird.
Protokolle für Single Sign-on
Die technische Umsetzung von Single Sign-on (SSO) hängt von der Anwendung, der vorhandenen Infrastruktur und den benötigten Identitätsdaten ab. In Unternehmensnetzwerken und Webanwendungen begegnen dir vor allem SAML, OpenID Connect und Kerberos. OAuth 2.0 wird ebenfalls häufig genannt, erfüllt allein aber eine andere Aufgabe.
| Verfahren | Technische Grundlage | Typischer Einsatz |
|---|---|---|
| SAML 2.0 | Signierte XML-Nachrichten | Unternehmenssoftware und webbasierte Dienste |
| OpenID Connect | Identitätsschicht auf Basis von OAuth 2.0, meist mit ID-Token | Webanwendungen, Apps und moderne Plattformen |
| Kerberos | Zeitlich begrenzte Tickets innerhalb einer vertrauenswürdigen Infrastruktur | Interne Netzwerke und Domänen |
| OAuth 2.0 | Delegierte Autorisierung über Access-Token | Freigabe begrenzter Zugriffe auf APIs und Daten |
SAML für Unternehmensanwendungen
SAML 2.0 übermittelt sogenannte Assertions zwischen Identity Provider und Service Provider. Eine Assertion kann bestätigen, welcher Nutzer angemeldet wurde und welche Attribute zu seinem Konto gehören. Der Service Provider muss dabei unter anderem Signatur, Empfänger, Gültigkeitszeitraum und vorgesehene Zieladresse kontrollieren.
OpenID Connect für Webentwicklung
OpenID Connect ergänzt OAuth 2.0 um eine standardisierte Identitätsprüfung. Der Identity Provider stellt dafür ein ID-Token aus, das Informationen über den Anmeldevorgang und den Nutzer enthält. Bei der Webentwicklung müssen unter anderem Aussteller, Zielgruppe, Signatur, Ablaufzeit und ein zufälliger Prüfwert validiert werden. Eine bloße Entschlüsselung des Tokens reicht nicht aus.
Abgrenzung zu verwandten Verfahren
Der Unterschied zwischen Single Sign-on (SSO) und einem Passwortmanager liegt in der Vertrauensstruktur. Ein Passwortmanager speichert mehrere Zugangsdaten und trägt sie in unterschiedliche Anmeldeformulare ein. Single Sign-on (SSO) ersetzt diese separaten Anmeldungen durch eine zentrale Identitätsprüfung und standardisierte Vertrauensbeziehungen.
Der Unterschied zwischen Single Sign-on (SSO) und Multi-Faktor-Authentifizierung liegt in der Aufgabe. Single Sign-on steuert, wie eine bestätigte Identität für mehrere Dienste verwendet wird. Multi-Faktor-Authentifizierung verlangt mindestens zwei unterschiedliche Nachweisarten, beispielsweise ein Passwort und einen Sicherheitsschlüssel. Beide Verfahren lassen sich kombinieren.
OAuth 2.0 ist kein eigenständiges Anmeldeprotokoll. OAuth 2.0 erlaubt einer Anwendung, mit begrenzter Berechtigung auf Daten oder Schnittstellen eines anderen Dienstes zuzugreifen. Erst OpenID Connect ergänzt den standardisierten Identitätsnachweis, der für eine Anmeldung benötigt wird.
Single Sign-on in der Webentwicklung
Bei der Webentwicklung beginnt Single Sign-on (SSO) mit einer klaren Rollenverteilung. Die Anwendung muss festlegen, welcher Identity Provider zulässig ist, welche Nutzerattribute benötigt werden und wie Rollen in interne Berechtigungen übersetzt werden. Ein übermitteltes Gruppenattribut sollte beispielsweise nicht ungeprüft administrativen Zugriff auslösen.
Eine belastbare Implementierung prüft mindestens folgende Punkte:
Single Sign-on (SSO) vereinfacht die Anmeldung, schafft aber einen zentralen Zugangspunkt. Wird ein zentrales Konto übernommen, können mehrere verbundene Anwendungen betroffen sein. Multi-Faktor-Authentifizierung, kurze Sitzungen für kritische Bereiche und protokollierte Anmeldeereignisse begrenzen dieses Risiko.
Auswirkungen auf SEO, SEA und GEO
Single Sign-on (SSO) betrifft SEO, wenn öffentliche Inhalte versehentlich hinter einer Anmeldung liegen. Suchmaschinen können geschützte Produktinformationen, Ratgeber oder Standortseiten ohne zugängliche HTML-Version gewöhnlich nicht crawlen und indexieren. Inhalte, die organisch gefunden werden sollen, müssen deshalb ohne Benutzerkonto erreichbar sein. Technische Zugangsfehler lassen sich im Rahmen eines SEO-Audits systematisch prüfen.
Bei SEA darf eine Anzeige nicht auf einer Landingpage enden, die sofort eine interne Anmeldung verlangt, sofern der Nutzer keinen bestehenden Zugang erwarten kann. Zusätzliche Weiterleitungen und unerwartete Login-Schritte erhöhen die Abbruchwahrscheinlichkeit. Eine auf den Kampagnenzweck abgestimmte Usability-Optimierung prüft deshalb auch den Weg vom Anzeigenklick bis zur gewünschten Aktion.
Für GEO, also Generative Engine Optimization, gilt dieselbe Zugänglichkeitsbedingung wie für SEO: Informationen hinter einem Login stehen öffentlich arbeitenden KI-Systemen normalerweise nicht als zitierbare Quelle zur Verfügung. Fachwissen, Produktmerkmale und Unternehmensinformationen benötigen frei erreichbare Seiten, wenn ChatGPT, Perplexity, Gemini oder andere Systeme sie erfassen und als Quelle verwenden sollen.
Single Sign-on prüfen und messen
Messbar ist Single Sign-on (SSO) zum Beispiel über die Quote erfolgreicher Anmeldungen: erfolgreiche SSO-Anmeldungen geteilt durch alle gestarteten SSO-Anmeldungen, multipliziert mit 100. Bei 940 erfolgreichen Anmeldungen aus 1.000 gestarteten Vorgängen beträgt die Erfolgsquote 94 Prozent. Der Wert sollte nach Anwendung, Browser und Fehlercode aufgeteilt werden, weil ein Gesamtwert die Fehlerursache nicht erkennen lässt.
Vor einem Relaunch müssen alle geschützten und öffentlichen Bereiche getrennt getestet werden. Eine vollständige Checkliste für den Website-Relaunch hilft dabei, Weiterleitungen, Indexierbarkeit und Anmeldepfade vor dem Livegang zu kontrollieren. Für Single Sign-on (SSO) gehören auch Testkonten mit unterschiedlichen Rollen sowie abgelaufene oder gesperrte Konten in den Prüfplan.
Häufige Fragen zu Single Sign-on
Ist Single Sign-on sicher?
Single Sign-on kann die Sicherheit erhöhen, weil Sicherheitsregeln und Multi-Faktor-Authentifizierung zentral durchgesetzt werden können. Der Identity Provider benötigt dafür einen besonders starken Schutz, da ein kompromittiertes Konto Zugriff auf mehrere verbundene Anwendungen ermöglichen kann.
Braucht Single Sign-on immer ein Passwort?
Single Sign-on schreibt kein Passwort vor. Der Identity Provider kann auch Sicherheitsschlüssel, Passkeys, Zertifikate oder biometrisch freigegebene Zugangsdaten verwenden. Welche Methode möglich ist, hängt vom Identity Provider und den angeschlossenen Anwendungen ab.
Was passiert, wenn der SSO-Dienst ausfällt?
Bei einem Ausfall können neue Anmeldungen scheitern, während bereits bestehende Sitzungen je nach Anwendung weiterlaufen. Unternehmen sollten deshalb Verfügbarkeit, Wiederherstellung und einen abgesicherten Notfallzugang für administrative Konten planen.
Kann man sich mit Single Sign-on überall gleichzeitig abmelden?
Eine zentrale Abmeldung ist möglich, wird aber nicht von jeder Anwendung gleich umgesetzt. Manche Dienste beenden nur ihre eigene Sitzung. Die Abmeldefunktion muss deshalb für jede angebundene Anwendung separat getestet werden.
Was ist der Unterschied zwischen SSO und Social Login?
Social Login verwendet ein bestehendes Konto bei einem externen Identitätsanbieter zur Anmeldung. Social Login kann technisch als Single Sign-on umgesetzt sein, bezeichnet aber speziell die Anmeldung über einen externen Verbraucherdienst.
Lohnt sich Single Sign-on für kleine Unternehmen?
Single Sign-on kann sich lohnen, sobald Mitarbeiter regelmäßig mehrere Cloud-Dienste verwenden oder Zugänge zentral verwaltet werden sollen. Die Entscheidung sollte sich an der Zahl der Anwendungen, dem Verwaltungsaufwand und den Sicherheitsanforderungen orientieren.
Wenn Login, öffentliche Inhalte und Suchmaschinenzugriff gemeinsam geplant werden sollen, kann eine technische Beratung die Anforderungen vor der Umsetzung strukturieren.
Sie haben noch Fragen?
