Single Sign-on (SSO) bezeichnet eine Identitätslösung, bei der mehrere Anwendungen dieselbe Authentifizierungssitzung nutzen und Anmeldedaten nicht mehrfach eingegeben werden müssen. SSO-Implementierungen werden häufig von Unternehmenskunden genutzt, um den sicheren Zugriff auf wichtige Ressourcen zu ermöglichen. Im Zeitalter der Cloud und bei zunehmender Nutzung von Software-as-a-Service (SaaS) legen Unternehmen weltweit ihren Schwerpunkt auf Zugangsverwaltungsstrategien, die sowohl die Sicherheit als auch das Nutzererlebnis verbessern; beide Aspekte profitieren von SSO.

Vom Standpunkt der Sicherheit aus betrachtet besteht ein Vorteil von Single Sign-on darin, dass sich die Anzahl der für die Anmeldung bei verschiedenen Diensten benötigten Anmeldedaten auf einen Satz reduziert und somit weniger Daten verloren gehen oder gestohlen werden können. Darüber hinaus ist es wahrscheinlich, dass zum Schutz dieses einen, wertvollen Satzes von Anmeldedaten eine Multi-Faktor-Authentifizierung (MFA) oder eine Zwei-Faktor-Authentifizierung (2FA) durchgesetzt wird.

Aus Sicht des Endnutzers sorgt der Einsatz eines IdP-Systems, das SSO unterstützt, für ein besseres Nutzererlebnis, da es die Passwortmüdigkeit bei der Eingabe drastisch reduziert. Außerdem entfällt mit SSO die Last, die entsteht, wenn man sich die Anmeldedaten für Dutzende von Konten einprägen muss.

Ein günstiger Nebeneffekt von SSO-Lösungen besteht darin, dass sich die Zahl der Anfragen zwecks Rücksetzung von Passwörtern beim Helpdesk ebenfalls verringert.

Single Sign-on umfasst in der Regel die Definition eines zentralen Dienstes, auf den sich Anwendungen bei der Anmeldung eines Nutzers verlassen. Wenn ein nicht authentifizierter Nutzer auf eine Anwendung zugreifen möchte, für die Identitätsdaten erforderlich sind, leitet die betreffende App den Nutzer an den zentralen Dienst um. Auf diesem Server authentifiziert sich der Nutzer und wird mit seinen geprüften Identitätsdaten wieder an die ursprüngliche Anwendung zurückgeleitet. Dort kann er das erledigen, was er vor der Authentifizierungsaufforderung ursprünglich tun wollte.

Wenn derselbe Nutzer nach einer Weile zu einer anderen Anwendung wechselt, für die ebenfalls Identitätsdaten erforderlich sind und die sich auf denselben zentralen Dienst für die Nutzerauthentifizierung verlässt, kann die zweite Anwendung von der Sitzung profitieren, die der Nutzer mit der Anmeldung bei der ersten Anwendung gestartet hat.

Ein gutes Beispiel dafür, wie SSO in der Praxis funktioniert, sind Google und seine verschiedenen Dienste. Wenn Sie beispielsweise versuchen, auf Gmail zuzugreifen, ohne sich authentifiziert zu haben, leitet Google Sie an einen zentralen Dienst auf accounts.google.com weiter. Dort sehen Sie ein Anmeldefenster, in das Sie Ihre Anmeldedaten eingeben müssen. Ist der Authentifizierungsprozess erfolgreich, leitet Google Sie an Gmail zurück, wo Sie auf Ihr E-Mail-Konto zugreifen können. Wenn Sie nach der Authentifizierung durch diesen zentralen Dienst zu einem anderen Dienst (wie beispielsweise YouTube) wechseln, sehen Sie, dass Sie automatisch angemeldet sind.

Das folgende Diagramm zeigt noch genauer, wie ein SSO-Authentifizierungsprozess abläuft.

Angenommen, der Nutzer möchte auf domain1.com zugreifen. Er wird dann an den Authentifizierungsserver domain3.com weitergeleitet, wo er sich authentifiziert. Verläuft dies erfolgreich, speichert domain3 ein Session-Cookie, der für den SSO-Datensatz verwendet wird. Der Browser wird wieder an domain1 verwiesen und erhält ein Artefakt mit auf den Weg, das domain1.com gegen ein Token umtauschen kann, das als Nachweis der Identität des Nutzers für den anschließenden Zugriff auf die Dienste von domain1 dient.

Wechselt der Nutzer (während derselben Sitzung) zu domain2.com, erfolgt eine Umleitung von domain2 zu domain3 zwecks Authentifizierung. Da domain3 jedoch bereits einen Datensatz hat, der zeigt, dass der Nutzer schon angemeldet ist (deshalb das Cookie), muss sich der Nutzer nicht noch einmal anmelden. Stattdessen wird der Browser mit dem entsprechenden Authentifizierungsartefakt wieder an domain2.com zurückgeleitet, wie zuvor.

Der Zeitraum, für den die SSO-Sitzung gültig bleibt, wird vom Authentifizierungsserver (domain3) bestimmt und kann von der Länge der Browsersitzung bis zu einem spezifizierten Zeitraum (von Stunden bis hin zu Wochen) reichen, je nach Sicherheitsrichtlinie und Anforderungen an das Nutzererlebnis.

Dies ist der Kernpunkt von SSO, wie man ihn von Google und anderen Diensten kennt. Das Protokoll zwischen dem Authentifizierungsserver und den Client-Anwendungen ist in der Regel SAML 2.0, OpenID Connect, Kerberos oder ein anderes Authentifizierungsprotokoll, das SSO unterstützt.

Wie bei vielen anderen Authentifizierungs- und Autorisierungsfunktionen ist die Implementierung von Single Sign-on über Auth0 kinderleicht. Wenn Sie Auth0 bereits zum Schutz Ihrer Anwendungen nutzen, steht Ihnen SSO automatisch zur Verfügung. Wenn Sie beispielsweise zwei oder mehr Anwendungen haben, die dasselbe Auth0-Konto nutzen, werden Sie bemerken, dass Nutzer, die sich bei einer Anwendung anmelden, automatisch transparent bei der anderen angemeldet werden. Bei diesen Anwendungen müssen Sie nichts weiter tun, um von der SSO-Sitzung zu profitieren.

Ein weiterer nützlicher Aspekt von Auth0 für Single Sign-on in Ihren Anwendungen ist der zentrale Kontrollpunkt für den Zugriff auf Ihre Ressourcen, was den Aufwand für Ihre IT-Abteilung verringert.

Weitere Informationen über Auth0 im Zusammenhang mit Single Sign-on zum Schutz Ihrer Anwendungen finden Sie in unserer Dokumentation.

Lesen Sie unsere Einführung in IAM, um sich über weitere Themen rund um das Identitäts- und Zugriffsmanagement zu informieren.