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. Die Zugangsdaten werden zentral durch einen Identitätsanbieter geprüft. Die einzelnen Anwendungen erhalten anschließend eine digital signierte Bestätigung der erfolgreichen Anmeldung, jedoch normalerweise nicht das Passwort selbst.
Wie funktioniert Single Sign-on (SSO)?
Single Sign-on (SSO), auf Deutsch auch Einmalanmeldung genannt, trennt die Prüfung der Identität vom Zugriff auf eine Anwendung. Ein zentraler Identitätsanbieter, kurz IdP, übernimmt die Anmeldung. Die angebundene Anwendung vertraut dem Ergebnis dieser Prüfung und wird als Service Provider bezeichnet. Dadurch muss sie keine eigenen Passwörter prüfen oder speichern.
Ruft ein Nutzer eine geschützte Anwendung ohne gültige Sitzung auf, leitet die Anwendung den Browser zum Identitätsanbieter weiter. Nach erfolgreicher Anmeldung erstellt der Identitätsanbieter eine signierte Aussage oder ein Token. Die Anwendung prüft Absender, Signatur, Empfänger, Gültigkeitsdauer und weitere Bedingungen. Stimmen diese Angaben, richtet die Anwendung eine eigene Sitzung ein.
Protokolle für Single Sign-on
Single Sign-on ist kein einzelnes Protokoll. Die technische Umsetzung hängt von den beteiligten Anwendungen, der Infrastruktur und dem gewünschten Einsatzzweck ab. In webbasierten Systemen werden vor allem SAML 2.0 und OpenID Connect verwendet. Kerberos kommt häufig in internen Unternehmensnetzwerken zum Einsatz.
| Verfahren | Technische Grundlage | Typischer Einsatz |
|---|---|---|
| SAML 2.0 | Signierte XML-Aussagen | Unternehmensanwendungen und ältere Websysteme |
| OpenID Connect | Identitätsschicht auf OAuth 2.0, häufig mit JWT | Webanwendungen, mobile Apps und moderne Plattformen |
| Kerberos | Zeitlich begrenzte Tickets | Interne Netzwerke und Windows-Umgebungen |
SAML 2.0
SAML 2.0 übermittelt Authentifizierungsinformationen als signierte XML-Aussagen. Der Service Provider prüft unter anderem, ob die Aussage für ihn bestimmt ist und innerhalb des angegebenen Zeitraums verwendet wird. SAML eignet sich besonders für browserbasierte Unternehmensanwendungen, ist wegen des XML-Formats jedoch umfangreicher als moderne tokenbasierte Verfahren.
OpenID Connect und OAuth 2.0
OpenID Connect bestätigt die Identität eines Nutzers und baut auf OAuth 2.0 auf. Ein ID-Token enthält Angaben zur Anmeldung und zur identifizierten Person. OAuth 2.0 allein ist dagegen ein Verfahren zur delegierten Autorisierung: Es regelt, auf welche Ressourcen eine Anwendung zugreifen darf. Der Unterschied liegt damit im Zweck. OpenID Connect beantwortet die Frage, wer der Nutzer ist, OAuth 2.0 beantwortet die Frage, was eine Anwendung tun darf.
Vorteile für Nutzer und Unternehmen
Single Sign-on reduziert die Zahl der erforderlichen Anmeldungen und bündelt die Zugriffsverwaltung. Ein Mitarbeiter kann beispielsweise mit einem zentralen Konto auf ein Intranet, ein Projektmanagement-System und ein Analyse-Dashboard zugreifen. Wird das Konto deaktiviert, kann der Zugriff auf alle angebundenen Anwendungen zentral entzogen werden, sofern die Systeme Sperrungen und Sitzungswiderrufe korrekt verarbeiten.
Single Sign-on ersetzt kein Berechtigungskonzept. Die zentrale Anmeldung bestätigt zunächst die Identität. Welche Bereiche, Daten oder Funktionen ein Nutzer anschließend verwenden darf, muss jede Anwendung anhand von Rollen, Gruppen oder anderen Merkmalen festlegen. Prüfe deshalb getrennt, ob die Authentifizierung funktioniert und ob die vergebenen Rechte tatsächlich zum Aufgabenbereich des Nutzers passen.
Sicherheit bei Single Sign-on
Single Sign-on kann die Sicherheit erhöhen, weil Mehrfaktor-Authentifizierung, Passwortregeln und Anmeldeprotokolle zentral durchgesetzt werden können. Gleichzeitig bündelt das Verfahren den Zugriff auf mehrere Systeme. Wird ein zentrales Konto übernommen und fehlt ein zweiter Faktor, kann ein Angreifer alle Anwendungen erreichen, denen der Identitätsanbieter eine gültige Anmeldung bestätigt.
Eine belastbare Umsetzung verbindet Single Sign-on deshalb mit mehreren Schutzebenen:
Ein häufiger Implementierungsfehler besteht darin, nur die digitale Signatur eines Tokens zu prüfen. Eine gültige Signatur bestätigt zwar die Herkunft, reicht aber allein nicht aus. Die Anwendung muss zusätzlich kontrollieren, ob das Token für genau diese Anwendung ausgestellt wurde, noch gültig ist und vom erwarteten Identitätsanbieter stammt. Andernfalls kann ein technisch korrekt signiertes Token im falschen Kontext akzeptiert werden.
Single Sign-on in der Webentwicklung
Bei der Entwicklung einer Website mit angebundenen Benutzerbereichen muss Single Sign-on früh in die Systemarchitektur einbezogen werden. Entwickler benötigen festgelegte Weiterleitungsadressen, eine sichere Token-Prüfung, eine Zuordnung externer Identitäten zu lokalen Konten und einen definierten Umgang mit abgelaufenen oder widerrufenen Sitzungen.
Auch die Abmeldung braucht eine klare Spezifikation. Eine Abmeldung aus einer Anwendung beendet nicht automatisch die Sitzung beim Identitätsanbieter oder in allen weiteren Anwendungen. Ein vollständiger Single Logout funktioniert nur, wenn das verwendete Protokoll und sämtliche beteiligten Systeme diesen Ablauf unterstützen. Prüfe daher getrennt, welche lokale Sitzung und welche zentrale Sitzung beim Abmelden beendet werden.
Auswirkungen auf SEO, SEA und GEO
Single Sign-on beeinflusst SEO, wenn öffentlich relevante Inhalte versehentlich hinter einer Anmeldung liegen. Suchmaschinen können geschützte Produktinformationen, Ratgeber oder Kategorieseiten in der Regel nicht wie frei erreichbare Inhalte crawlen und indexieren. Öffentlich auffindbare Seiten sollten deshalb ohne Anmeldung einen HTTP-Statuscode 200 und den vollständigen indexierbaren Inhalt ausliefern. Nutzerkonten, interne Dashboards und persönliche Daten gehören dagegen in den geschützten Bereich.
Für SEA müssen Zielseiten aus Anzeigen ohne vorherige Anmeldung erreichbar sein, sofern die Kampagne neue Interessenten anspricht. Eine Weiterleitung auf eine Anmeldeseite verändert den erwarteten Nutzerweg und kann die Conversion beeinträchtigen. Eine klare Nutzerführung und Usability trennt deshalb öffentliche Landingpages von geschützten Funktionen.
Für GEO, also Generative Engine Optimization, gilt dieselbe technische Grenze: KI-Systeme können öffentlich zugängliche, crawlbare Informationen eher erfassen und als Quelle verwenden als Inhalte in einem geschlossenen Kundenbereich. Unternehmen sollten Definitionen, Leistungsinformationen und fachliche Nachweise öffentlich bereitstellen. Persönliche Auswertungen und vertrauliche Daten bleiben durch Single Sign-on geschützt. Ein technischer SEO-Check sollte deshalb auch unbeabsichtigte Login-Weiterleitungen und gesperrte öffentliche URLs erfassen.
Abgrenzung zu verwandten Verfahren
Der Unterschied zwischen Single Sign-on und einem Passwortmanager liegt in der Authentifizierung. Ein Passwortmanager speichert unterschiedliche Zugangsdaten und trägt sie bei den jeweiligen Diensten ein. Single Sign-on nutzt dagegen eine zentrale Identität und übermittelt den Anwendungen eine vertrauenswürdige Bestätigung der Anmeldung. Die angebundene Anwendung erhält üblicherweise kein separates Passwort.
Single Sign-on ist außerdem nicht mit demselben Passwort für mehrere Konten gleichzusetzen. Wiederverwendete Passwörter bleiben voneinander getrennte Anmeldungen und erhöhen das Risiko bei einem Datenleck. Bei Single Sign-on existiert eine kontrollierte Vertrauensbeziehung zwischen dem Identitätsanbieter und den angeschlossenen Anwendungen.
Häufige Fragen zu Single Sign-on
Ist Single Sign-on sicher?
Single Sign-on kann sicherer als viele getrennte Anmeldungen sein, wenn Mehrfaktor-Authentifizierung, kurze Token-Laufzeiten und eine vollständige Token-Prüfung eingesetzt werden. Das zentrale Konto muss besonders geschützt werden, weil es den Zugang zu mehreren Anwendungen ermöglicht.
Braucht Single Sign-on weiterhin ein Passwort?
Das hängt vom Identitätsanbieter ab. Häufig meldet sich der Nutzer einmal mit Passwort und einem zweiten Faktor an. Möglich sind auch passwortlose Verfahren mit Sicherheitsschlüsseln, biometrischen Merkmalen oder Gerätebestätigungen.
Was passiert, wenn der Identitätsanbieter ausfällt?
Ohne erreichbaren Identitätsanbieter können neue Anmeldungen scheitern. Bereits bestehende Sitzungen können je nach Anwendung weiter funktionieren, bis ihre Gültigkeit endet. Für geschäftskritische Systeme sind deshalb Verfügbarkeit, Ausweichverfahren und Wiederherstellungsprozesse festzulegen.
Kann Single Sign-on mehrere Domains verbinden?
Ja, Single Sign-on kann Anwendungen auf unterschiedlichen Domains verbinden. Die gemeinsame Anmeldung entsteht nicht durch ein domainübergreifendes Cookie, sondern durch Weiterleitungen und signierte Nachrichten zwischen den Anwendungen und dem Identitätsanbieter.
Was ist der Unterschied zwischen SSO und MFA?
SSO reduziert die Zahl der Anmeldungen, MFA verlangt mehrere voneinander unabhängige Nachweise für eine Anmeldung. Beide Verfahren lassen sich kombinieren: Der Nutzer bestätigt seine Identität mit mehreren Faktoren und erhält danach Zugriff auf mehrere verbundene Anwendungen.
Meldet Single Sign-on automatisch überall ab?
Nein, eine lokale Abmeldung beendet nicht zwingend alle weiteren Sitzungen. Eine zentrale Abmeldung setzt voraus, dass der Identitätsanbieter, das Protokoll und jede angebundene Anwendung den entsprechenden Abmeldeprozess korrekt unterstützen.
Wenn du Single Sign-on in einen Relaunch, einen Kundenbereich oder eine neue Plattform integrieren möchtest, sollte die Planung Technik, Nutzerführung und öffentliche Auffindbarkeit gemeinsam berücksichtigen.
Sie haben noch Fragen?
