Was ist Single-Sign-On (SSO)? | Okta

Single Sign-On (SSO) ist ein Verfahren zur Benutzerauthentifizierung, mit dem Benutzer mit nur einem Satz Anmeldedaten sicher auf mehrere Anwendungen und Services zugreifen können. Wenn Sie Slack, Asana, Google Workspace oder Zoom beruflich nutzen, können Sie mit SSO über ein Pop-up-Widget oder eine Anmeldeseite mit nur einem Passwort auf jede integrierte Anwendung zugreifen. So müssen Sie nicht jeden Tag zwölf Passwörter eingeben, sondern benötigen nur ein einziges – die Sicherheit wird durch SSO gewährleistet.

Dank Single Sign-On müssen Sie sich nicht mehr viele Passwörter merken und diese eingeben. Das frustrierende Zurücksetzen vergessener Passwörter entfällt ebenfalls. Die Benutzer können auf verschiedenste Plattformen und Anwendungen zugreifen, ohne sich bei allen einzeln anmelden zu müssen.

Wie funktioniert SSO?

SSO basiert auf dem Konzept der föderierten Identität, bei dem Identitätsattribute über vertrauenswürdige, aber autonome Systeme geteilt werden. Wenn ein Benutzer von einem System als vertrauenswürdig eingestuft wird, erhält er automatisch Zugriff auf alle anderen Systeme, die bei diesem eine Vertrauensstellung haben. Dies bildet die Grundlage moderner SSO-Lösungen, die Protokolle wie OpenID Connect und SAML 2.0 nutzen.

Wenn sich ein Benutzer über SSO bei einem Service anmeldet, wird ein Authentifizierungs-Token erstellt und entweder in seinem Browser oder auf den Servern der SSO-Lösung gespeichert. Jede Anwendung oder Website, auf die der Benutzer danach zugreift, führt eine Prüfung beim SSO-Service durch. Dieser sendet dann den Token des Benutzers, um seine Identität zu bestätigen und ihm Zugriff zu geben.

Formen von SSO

Es gibt eine Vielzahl von Protokollen und Standards, die Sie bei der Identifikation und Arbeit mit SSO kennen sollten. Dazu gehören: 

• Security Access Markup Language (SAML): SAML ist ein offener Standard, durch den Text in Maschinensprache codiert und der Austausch von Identifikationsdaten ermöglicht wird. Er hat sich zu einem der grundlegenden Standards für SSO entwickelt und hilft Anwendungsanbietern sicherzustellen, dass ihre Authentifizierungsanfragen zulässig sind. SAML 2.0 ist speziell für die Verwendung in Webanwendungen optimiert, sodass Informationen über einen Webbrowser übermittelt werden können.
• Open Authorization (OAuth): OAuth ist ein auf einem offenen Standard basierendes Autorisierungsprotokoll, durch das Identifikationsdaten zwischen Applikationen übertragen und in Maschinencode verschlüsselt werden. Dadurch können Benutzer einer Anwendung Zugriff auf ihre Daten in einer anderen Anwendung gewähren, ohne dass sie ihre Identität manuell validieren müssen. Dies ist vor allem bei nativen Applikationen praktisch.
• OpenID Connect (OIDC): OIDC setzt auf OAuth 2.0 auf. Es liefert zusätzliche Informationen über den Benutzer und ermöglicht den SSO-Prozess. Mit OIDC kann eine Anmeldesitzung für mehrere Anwendungen verwendet werden. Es sorgt beispielsweise dafür, dass sich ein Benutzer über sein Facebook- oder Google-Konto bei einem Service anmelden kann, statt seine Benutzeranmeldedaten einzugeben.
• Kerberos: Kerberos ist ein Protokoll, das eine gegenseitige Authentifizierung ermöglicht. Dabei führen der Benutzer und der Server bei unsicheren Netzwerkverbindungen eine wechselseitige Identitätsprüfung durch. Kerberos nutzt einen Ticketausstellungsservice, der Token für die Authentifizierung von Benutzern und Software-Anwendungen wie E-Mail-Clients oder Wiki-Servern ausgibt.
• Smartcard-Authentifizierung: Neben herkömmlichem SSO gibt es auch Hardware, die diesen Prozess vereinfachen kann, beispielsweise physische Smartcard-Leser, die die Benutzer an ihre Computer anschließen. Eine Software auf dem Computer interagiert dann mit kryptographischen Schlüsseln auf der Smartcard, um den Benutzer zu authentifizieren. Smartcards sind ausgesprochen sicher und können erst nach der Eingabe einer PIN genutzt werden. Allerdings müssen die Benutzer sie physisch bei sich haben – es besteht also das Risiko, dass sie verloren gehen – und ihre Nutzung kann mit hohen Kosten verbunden sein.

Die Geschichte von SSO

Die SSO-Technologie hat ihren Ursprung in lokalen Identitätstools, über die Unternehmen Mitte bis Ende der 1990er Jahre ihre Computer, Netzwerke und Server sicher miteinander verbinden konnten. Damals begannen die Unternehmen, ihre Benutzeridentitäten über dedizierte Systeme wie Active Directory (AD) und Lightweight Directory Access Protocol (LDAP) von Microsoft zu verwalten, und sicherten den Zugriff dann über lokale SSO- oder Web Access Management (WAM)-Tools ab.

Da sich die IT durch den Wechsel in die Cloud, die Verteilung auf mehrere Geräte und die Konfrontation mit immer ausgeklügelteren Cyberbedrohungen immer weiter entwickelt, können diese herkömmlichen Identitätsmanagementtools nicht mehr mithalten. Die IT-Teams benötigen nun eine Lösung, die Benutzern schnellen, sicheren Single Sign-On-Zugriff auf alle Anwendungen und Services ermöglicht.

SSO-Mythen aufgedeckt

Es gibt zahlreiche Missverständnisse rund um das Thema SSO. Sie werden jedoch kontinuierlich durch moderne Lösungen ausgeräumt. Gängige SSO-Mythen sind unter anderem:

SSO-Mythos 1: SSO bremst IT-Teams aus und erhöht ihre Arbeitsbelastung

Im Gegenteil. SSO verhilft den IT-Teams zu mehr Effektivität, da es die Automatisierung steigert, mehr Sicherheit und Transparenz bietet und bessere Arbeitsabläufe ermöglicht. Es unterstützt die IT-Teams direkt bei ihrer Kernaufgabe – dafür zu sorgen, dass die Mitarbeiter reibungslos, sicher und schnell auf die Tools zugreifen können, die sie zur Erledigung ihrer Aufgaben benötigen. SSO ermöglicht auch eine schnellere Skalierung, umfassendere Einblicke in den Anwendungszugriff, eine geringere Anzahl von Helpdesk-Tickets sowie eine Senkung der IT-Kosten.

SSO-Mythos 2: Es ist schwierig, SSO zu implementieren

Veraltete Tools mögen zu ihrer Zeit komplex gewesen sein, doch modernes SSO lässt sich schnell und einfach bereitstellen. Die heutigen SSO-Tools besitzen integrierte Konnektoren zu Tausenden beliebten Anwendungen. Dadurch müssen die IT-Teams die entsprechenden Integrationen nicht manuell erstellen. Außerdem können Unternehmen Benutzern Zugriff gewähren und Informationen aus bestehenden Verzeichnissen importieren, ohne dass sie Hardware konfigurieren, installieren oder Support dafür bereitstellen bzw. Änderungen an der Firewall vornehmen müssen. SSO lässt sich einfach implementieren, zentralisiert das Onboarding von neuen Benutzern und Anwendungen, ist hochverfügbar und minimiert die Kosten. Gleichzeitig gewährleistet es einen einfachen und trotzdem sicheren Zugriff.

SSO-Mythos 3: SSO schafft eine zentrale Fehlerquelle (Single Point of Failure) und ist daher weniger sicher

Da bei SSO nur ein Passwort erforderlich ist, mag es naheliegend erscheinen, dass es einen attraktiven Angriffsvektor für Cyberbedrohungen bietet. Tatsächlich gibt es jedoch schon eine zentrale Fehlerquelle: den Benutzer. Wenn Benutzer mit unterschiedlichen Anmeldedaten arbeiten müssen, neigen sie oft zur Wiederverwendung von Passwörtern und zu einer schlechten Passworthygiene. Dies stellt für Unternehmen ein Sicherheitsrisiko dar. Bei SSO gehören mehrere Anmeldedaten der Vergangenheit an. Die IT-Teams können Passwortrichtlinien festlegen, durch die reguläre Sicherheitsprotokolle standardisiert werden. Gleichzeitig wird bei jeder Zugriffsanfrage der Anwendungs-, Benutzer-, Geräte-, Standort- und Netzwerkkontext überwacht.

SSO-Mythos 4: SSO ist dasselbe wie ein Passwortmanager

Über SSO und Passwortmanager können Benutzer mit einer Anmeldung auf mehrere Anwendungen zugreifen. Damit enden die Ähnlichkeiten aber auch schon. Passwortmanager sind „Tresore“, in denen die Anmeldedaten der Benutzer für verschiedene Applikationen oder Websites – geschützt durch ein primäres Passwort – gespeichert sind. Ihr Schwerpunkt liegt jedoch auf dem Schutz von Passwörtern, die die Ursache für über 80 % aller Sicherheitsverletzungen sind und somit für Hacker ein potenzielles Einfallstor in ein Unternehmen oder eine Identität darstellen. SSO-Lösungen hingegen verwalten den Zugriff vertrauensbasiert und nutzen bestehende Beziehungen, um eine einzelne Domäne zu erstellen, in der die Authentifizierung stattfindet.