Was ist Single Sign-On SSO? | phoenixNAP IT-Glossar

Single Sign-On (SSO) ist eine Authentifizierungsmethode, die es Benutzern ermöglicht, mit einem einzigen Satz von Anmeldeinformationen auf mehrere Anwendungen oder Dienste zuzugreifen.

Was ist Single Sign-On?

Single Sign-On ist ein Identitätsföderationsmuster, bei dem sich ein Benutzer einmalig bei einem vertrauenswürdigen Identitätsanbieter (IdP) authentifiziert und anschließend kryptografisch signierte Zusicherungen oder Token erhält, die von anderen Benutzern verwendet werden können. Anwendungen (sogenannte Dienstanbieter) akzeptieren diese als Identitätsnachweis. Nach der ersten Anmeldung stellt der Identitätsanbieter zeitlich begrenzte Anmeldeinformationen (z. B. SAML-Assertions oder OpenID Connect ID-Token) aus, die der Browser or Auftraggeber stellt jeder Anwendung eine Vorlage zur Verfügung, die Signatur, Zielgruppe und Ablaufdatum überprüft, bevor sie ihre eigene Sitzung einrichtet.

Da das Vertrauen im Identitätsanbieter (IdP) verankert und durch standardbasierte Protokolle vermittelt wird, ermöglicht SSO unabhängigen Systemen, eine einheitliche Sichtweise darauf zu teilen, wer der Benutzer ist, welche Attribute er besitzt und wie lange sein Konto besteht. Beglaubigung sollte als gültig angesehen werden.

Arten von Single Sign-On

Nachfolgend sind die gängigsten Typen aufgeführt und was jeder einzelne bewirkt.

SAML 2.0 Federation

Security Assertion Markup Language (SAML) ist ein XML-basierter Standard, der für browserbasiertes SSO bei Unternehmensanmeldungen weit verbreitet ist. SaaSNach der Authentifizierung beim Identitätsanbieter (IdP) erhält der Browser des Benutzers eine signierte SAML-Assertion, die der Dienstanbieter (SP) validiert, um eine Sitzung herzustellen.

SAML ist ausgereift, eignet sich hervorragend für die Freigabe von Unternehmensattributen (Rollen, Gruppen) und ist gängig für HRIS-zu-SaaS- und ADFS-zu-cloud Integrationen.

OpenID-Connect (OIDC)

OIDC basiert auf OAuth 2.0 und verwendet JSON Web Tokens (JWTs) zur Identitätsprüfung. Nach der Authentifizierung beim Identitätsanbieter (IdP) erhält der Client ein ID-Token (das seine Identität bestätigt) und häufig auch ein Zugriffstoken (das, worauf er zugreifen kann).

OIDC ist leichter als SAML, mobil und API-freundlich und ideal für moderne Netz und mobile Apps, Single-Page-Anwendungen (SPAs) und Microservices die standardisierte, kompakte Token benötigen.

Kerberos/Integrierte Windows-Authentifizierung (IWA)

Bei Kerberos-basiertem SSO (z. B. mit Active Directory) bezieht das Betriebssystem ein Ticket von einem Key Distribution Center und stellt es den Diensten transparent zur Verfügung. Dadurch wird ein „stilles“ SSO in Unternehmensnetzwerken ermöglicht. Es ist schnell, unterstützt gegenseitige Authentifizierung und eignet sich hervorragend für lokale Anwendungen und Intranets, da moderne Umgebungen häufig Kerberos-Identitäten mit anderen Systemen verbinden. cloud über Föderation.

OAuth 2.0-gestütztes SSO (tokenbasierter Zugriff)

OAuth selbst ist ein Autorisierungsframework, kein Identitätsprotokoll. Viele SSO-Implementierungen kombinieren es jedoch mit OIDC oder benutzerdefinierten Identitätsendpunkten, damit sich Benutzer einmalig anmelden und Zugriffstoken für APIs erhalten können. Das Ergebnis ist SSO über Web- und Serviceebenen hinweg mit kurzlebigen Token, Bereichen und Aktualisierungsabläufen, die für … geeignet sind. Zero-Trust-Designs.

WS-Federation (WS-Fed)

Ein älteres, SOAP-orientiertes Microsoft-Federationsprotokoll, das in älteren ADFS- und SharePoint-Szenarien noch immer verwendet wird. Es ermöglicht browserbasiertes Single Sign-On (SSO) ähnlich wie SAML, ist aber in Greenfield-Projekten weniger verbreitet. Stattdessen migrieren Unternehmen ihre WS-Fed-Anwendungen häufig im Rahmen der Migration zu OIDC/SAML. cloud Modernisierung.

CAS (Zentraler Authentifizierungsdienst)

Dies ist ein einfaches, ticketvergebendes Protokoll, das im Hochschulbereich weit verbreitet ist. Benutzer authentifizieren sich an einem zentralen CAS. serverCAS stellt Service-Tickets aus, die von Anwendungen validiert werden. Es ist einfach zu bedienen und zu erweitern, verfügt aber nicht über die umfangreicheren Claim- und Token-Systeme von SAML/OIDC.

Reverse-Proxy/Header-basiertes SSO

Ein Gateway authentifiziert Benutzer (via Kerberos, SAML, OIDC oder MFA) und fügt Identitäts-Header (z. B. X-Remote-User) in Backend-Anwendungen ein, die keine Verbundprotokolle unterstützen. Es eignet sich zur Nachrüstung älterer Anwendungen, die Sicherheit hängt jedoch davon ab, dass ausschließlich den genannten Schnittstellen strikt vertraut wird. Stellvertreter und die Absicherung des direkten App-Zugriffs.

Passwortverwaltung/Formularbasierte SSO

Als letzte Möglichkeit für Anwendungen ohne Föderationsunterstützung speichert ein Zugriffsgateway die Anmeldeinformationen der einzelnen Benutzer sicher und meldet sie programmatisch an. Dies erhöht den Komfort, bietet aber keine echte Föderation und Aufgaben wie die Rotation von Anmeldeinformationen MFA Die Durchsetzung und Überprüfung gestalten sich komplexer als bei standardbasiertem SSO.

Wie funktioniert Single Sign-On?

SSO ermöglicht es einem Benutzer, sich einmalig bei einem vertrauenswürdigen Identitätsanbieter zu authentifizieren und diesen Nachweis anschließend für den sicheren Zugriff auf zahlreiche Anwendungen (Dienstanbieter, SPs) wiederzuverwenden. So funktioniert es genau:

Initiierung und IdP-Erkennung. Der Benutzer versucht, eine App zu öffnen. Die App (SP) erkennt keine lokale Sitzung und leitet den Benutzer (oft über SAML/OIDC-Metadaten) zum richtigen IdP weiter, um die Vertrauensstellung und den Anmeldevorgang zu gewährleisten.
Benutzerauthentifizierung beim Identitätsanbieter. Der IdP validiert die Identität mithilfe konfigurierter Methoden, wie z. B. eines Passworts und MFA, Passkeys oder Gerätestatusprüfungen, und erstellt dabei einen neuen Authentifizierungskontext mit einem präzisen Zeitstempel und einem genauen Sicherheitsniveau.
Token-/Assertionsausgabe. Bei erfolgreicher Authentifizierung stellt der Identitätsanbieter (IdP) eine signierte, zeitlich begrenzte Anmeldeinformation (z. B. SAML-Assertion, OIDC-ID-Token und Zugriffstoken) aus, die die Kennung und die Ansprüche/Attribute des Benutzers enthält.
Sichere Zustellung zurück an die App. Der Browser oder Client kehrt über eine sichere Verbindung (POST/Redirect-Token-Austausch im Front- oder Backchannel) mit den Anmeldeinformationen zum Service Provider zurück, wodurch die Integrität gewahrt und Manipulationen oder Wiederholungsangriffe verhindert werden.
Verifizierung und Sitzungserstellung. Der SP validiert die Stempel, UnterschriftZielgruppe, Aussteller, Nonce und Ablaufdatum. Bei erfolgreicher Prüfung wird eine App-Sitzung (Cookie oder Token) eingerichtet und die Autorisierung anhand von Rollen oder Ansprüchen angewendet.
Token-Aktualisierung und -Erhöhung (falls erforderlich). Mit zunehmendem Alter der Sitzungen oder steigender Zugriffssicherheit verwendet der Client Aktualisierungs- oder Re-Auth-Abläufe, um neue Token zu erhalten oder die Multi-Faktor-Authentifizierung zu erhöhen, wodurch der Zugriff ohne wiederholte vollständige Anmeldungen aufrechterhalten wird.
Abmeldung und Widerruf. Wenn sich der Benutzer abmeldet oder ein Risiko erkannt wird, beendet der Service Provider (SP) seine Sitzung. Optional kann Single Logout (SLO) oder ein Back-Channel-Widerruf beim Identity Provider (IdP) die Abmeldung an andere Anwendungen weitergeben, um verbleibende Sitzungen zu schließen.

Was ist ein Beispiel für ein SSO?

Ein Beispiel für Single Sign-On (SSO) ist, wenn ein Mitarbeiter Salesforce ohne lokale Sitzung nutzt. Salesforce leitet ihn dann zu Okta (dem Identitätsanbieter des Unternehmens) weiter. Der Benutzer meldet sich bei Okta an und führt die Multi-Faktor-Authentifizierung (MFA) durch. Okta stellt daraufhin eine signierte, kurzlebige SAML-Assertion aus, die die Benutzer-ID und die Rollen des Benutzers enthält.

Der Browser sendet diese Bestätigung an Salesforce zurück, welches Signatur, Zielgruppe und Ablaufdatum überprüft, anschließend eine eigene Sitzung erstellt und die Benutzerberechtigungen anwendet. Daher ist kein separates Salesforce-Passwort erforderlich. Bei nachfolgenden Anmeldungen an anderen verbundenen Anwendungen (z. B. ServiceNow, Box) wird die Okta-Sitzung wiederverwendet, wodurch ein nahtloser Zugriff über alle Anwendungen hinweg mit zentralisierter Richtlinien- und Protokollierung gewährleistet wird.

Was sind die Vor- und Nachteile von Single Sign-On?

Single Sign-On vereinfacht den Zugriff, indem sich Nutzer nur einmal authentifizieren müssen und so auf viele Anwendungen zugreifen können. Dies verbessert die Benutzerfreundlichkeit und zentralisiert die Sicherheitskontrollen. Die Konzentration der Authentifizierung birgt jedoch auch Risiken und Komplexität: Fällt die Identitätsprüfung aus oder ist sie falsch konfiguriert, sind viele Anwendungen gleichzeitig betroffen. Daher ist ein sorgfältiges Design erforderlich, um ein ausgewogenes Verhältnis zwischen Benutzerfreundlichkeit und hohen Sicherheitsvorkehrungen zu gewährleisten.

Welche Vorteile bietet Single Sign-On?

SSO verbessert die Benutzerfreundlichkeit und zentralisiert die Kontrolle durch die föderierte Authentifizierung über einen vertrauenswürdigen Identitätsanbieter. Hier die wichtigsten Vorteile:

Weniger Passwörter, bessere Benutzererfahrung. Nutzer melden sich einmal an und haben Zugriff auf alle Apps, wodurch Reibungsverluste und Anmeldemüdigkeit reduziert werden.
Stärkere Sicherheitskontrollen. Zentralisierte Multi-Faktor-Authentifizierung, Passkeys, Gerätestatusprüfungen und bedingter Zugriff gelten einheitlich für alle Apps.
Schnelleres Onboarding/Offboarding. Die Gewährung oder der Entzug des Zugriffs erfolgt über einen einzigen Identitätsdatensatz, sodass sich Änderungen auf alle verbundenen Dienste auswirken.
Geringere Supportkosten. Weniger Passwortzurücksetzungen und Kontosperrungen bedeuten weniger Helpdesk-Tickets.
Konsequente Regierungsführung. Rollen, Gruppen und attributbasierte Richtlinien werden überall auf die gleiche Weise durchgesetzt und unterstützen so geringstes Privileg.
Bessere Transparenz und Kontrollmöglichkeiten. Zentrale Protokolle und standardisierte Token vereinfachen die Überwachung. Vorfallreaktionund Compliance-Berichterstattung.
Reduziert Phishing Risiko. Die Nutzer erkennen einen einzigen, sicheren IdP-Anmeldevorgang, sodass es weniger anwendungsspezifische Passwörter zu stehlen gibt.
Moderne App- und API-Bereitschaft. Standards (OIDC/SAML/OAuth) ermöglichen den sicheren Zugriff auf Web-, Mobil- und Microservices mit kurzlebigen Token.
Sichereres Änderungsmanagement. Token-Lebensdauern, Sitzungsrichtlinien und Step-up-Authentifizierung ermöglichen es Ihnen, die Sicherheit für sensible Aktionen ohne neue Anmeldungen zu erhöhen.
Verbesserte Produktivität. Nahtloser, appübergreifender Zugriff verkürzt Kontextwechsel und beschleunigt Arbeitsabläufe.

Was sind die Nachteile von Single Sign-On?

Die Zentralisierung der Authentifizierung bietet zwar echte Vorteile, birgt aber auch technische und betriebliche Risiken, die es zu bewältigen gilt. Hier die wichtigsten Herausforderungen:

Der Punkt des Versagens und Explosionsradius. Wenn der Identitätsanbieter (IdP) ausfällt oder falsch konfiguriert ist, sind viele Anwendungen gleichzeitig nicht mehr erreichbar.
Risiko einer Fehlkonfiguration. Eine schwache Tokenvalidierung (Zielgruppe/Aussteller/Nonce), lange Ablaufzeiten oder eine zu freizügige Attributfreigabe können Tür und Tor für Identitätsdiebstahl und schleichende Rechteausweitung öffnen.
Sitzungs- und Tokenhygiene. Die Balance zwischen Komfort und Sicherheit (z. B. Verwaltung von Leerlauf- und absoluten Timeouts, Refresh-Tokens, Step-up-MFA) ist knifflig, und übermäßig lange Sitzungen erhöhen das Übernahmerisiko.
Zertifikat und Schlüsselverwaltung. Rotierende Signaturschlüssel, Handhabung Metadaten Aktualisierungen und Zeitabweichungen erfordern disziplinierte Betriebsabläufe, sonst können Anmeldeversuche unbemerkt fehlschlagen.
Abmeldekomplexität. Die Unterstützung für Single Logout (SLO) ist inkonsistent, und es bleiben Restsitzungen der App zurück.
Legacy- und Sonderfälle. Nicht-föderierte Anwendungen erzwingen die Speicherung von Passwörtern oder die Header-Injektion, was zu Anfälligkeit und schwächerer Sicherheit als bei echter Föderation führt.
Kontoverknüpfung und Lebenszyklus. Die Zuordnung von Identitäten über Verzeichnisse und Mandanten hinweg, die Just-in-Time-Bereitstellung und die rechtzeitige Deaktivierung sind ohne sauberes HR fehleranfällig. IAM Quellen.
Ausuferung der Zugangsrichtlinien. Bedingter Zugriff, Gerätestatus und app-spezifische Ausnahmen können schwer nachvollziehbar werden und zu Ausfällen oder Lücken führen.
Verkäufer und die Festlegung von Standards. Proprietäre Funktionen oder Protokollbesonderheiten verteuern Migrationen und erschweren Multi-IdP-Strategien.
Datenschutz und Datenminimierung. Die übermäßige Weitergabe von Attributen über verschiedene Apps hinweg erhöht die Offenlegungssicherheit, daher sind Mechanismen zur Minimierung der Attributfreigabe und zur Kontrolle der Einwilligung erforderlich.
Konzentration auf Phishing und Missbrauch. Ein einzelner, gehärteter Workflow ist hilfreich, aber wenn Angreifer die Anmeldeinformationen/Sitzung des Identitätsanbieters (IdP) erbeuten, erlangen sie weitreichenden Zugriff.

Häufig gestellte Fragen zur einmaligen Anmeldung

Hier finden Sie die Antworten auf die am häufigsten gestellten Fragen zum Thema Single Sign-On.

Was ist der Unterschied zwischen SSO und AD?

Lassen Sie uns die Unterschiede zwischen Single Sign-On und Active Directory (AD) genauer betrachten:

Aspekt	Single Sign-On (SSO)	Active Directory (AD)
Definition	Eine Authentifizierungsmethode, die es Benutzern ermöglicht, mit einem einzigen Login über einen zentralen Identitätsanbieter auf mehrere Systeme zuzugreifen.	Ein von Microsoft entwickelter Verzeichnisdienst zum Speichern und Verwalten von Benutzern, Computern und Richtlinien innerhalb einer Windows-Domäne.
Primärfunktion	Ermöglicht die Verbundauthentifizierung über mehrere Anwendungen und Dienste hinweg, oft über verschiedene Domänen oder Plattformen hinweg.	Verwaltet lokale Netzwerkidentitäten, Ressourcen und Sicherheitsrichtlinien in Windows-basierten Umgebungen.
Geltungsbereich	Plattformübergreifend und cloud-freundlich; funktioniert mit Webanwendungen, SaaS und APIs.	Primär lokal und Windows-zentriert, kann aber in Azure AD integriert werden für cloud verwenden.
Authentifizierungsmechanismus	Nutzt Verbundprotokolle wie SAML, OAuth 2.0 oder OpenID Connect.	Verwendet Kerberos und NTLM zur Authentifizierung innerhalb einer Windows-Domäne.
Identitätsspeicherung	Setzt auf einen externen Identitätsanbieter (IdP) zurück, der Benutzer authentifiziert und Token ausgibt.	Speichert Benutzer- und Computerkonten in einem zentralen LDAP-basierten Verzeichnis.
Zugriffsmodell	Ermöglicht den Zugriff auf mehrere unabhängige Anwendungen nach einmaliger Authentifizierung.	Ermöglicht den Zugriff auf Netzwerkressourcen (Dateifreigaben, Drucker, Domain Dienstleistungen) innerhalb einer einzigen Organisation.
User Experience	Ein Login gewährt Zugriff auf viele cloud und Webanwendungen nahtlos.	Benutzer melden sich automatisch in ihrem Domänenkonto an, um auf interne Ressourcen zuzugreifen.
Umsetzung	Kann mithilfe von Identitätsanbietern wie Okta, Azure AD, Ping Identity oder Google Workspace bereitgestellt werden.	Ist in Windows integriert. Server Umgebungen als Teil der Domänenverwaltung.
Anwendungsfall	Vereinheitlichung der Authentifizierung für cloud, SaaS und Hybridumgebungen.	Zentralisierung der Identitäts- und Zugriffskontrolle für Windows-Unternehmensnetzwerke.
Beziehung	SSO kann AD als Identitätsquelle nutzen; AD kann als Backend-Verzeichnis für eine SSO-Lösung fungieren.	Active Directory bildet häufig die Grundlage für Single Sign-On (SSO), indem es das Benutzerverzeichnis und die Kerberos-Tickets bereitstellt, die bei der integrierten Authentifizierung verwendet werden.

Ist Single Sign-On sicher?

Ja, bei korrekter Implementierung ist Single Sign-On (SSO) sehr sicher, da es strenge Sicherheitskontrollen (Multi-Faktor-Authentifizierung/Passwörter, bedingter Zugriff, Gerätestatusprüfungen) bei einem gehärteten Identitätsanbieter zentralisiert und kurzlebige, signierte Token ausgibt, die von jeder Anwendung verifiziert werden. Die Hauptrisiken liegen eher in der Architektur als im SSO selbst. Ein Ausfall oder eine Fehlkonfiguration des Identitätsanbieters kann viele Anwendungen beeinträchtigen, und langlebige oder schwach validierte Token erhöhen das Risiko einer Übernahme.

SSO sollte außerdem mit dem Prinzip der minimalen Berechtigungen, strenger Token-Validierung (Aussteller/Zielgruppe/Nonce/Ablauf), Schlüsselrotation und Zeitsynchronisierung, kontinuierlicher Überwachung mit Anomalieerkennung, mehrstufiger Authentifizierung für sensible Aktionen und einer robusten IdP-Architektur (Redundanz, Ratenbegrenzung) kombiniert werden. DDoS SchutzMit diesen Sicherheitsvorkehrungen verbessert SSO in der Regel die Sicherheit gegenüber isolierten, anwendungsspezifischen Anmeldungen.

Lohnt sich Single Sign-On?

Ja, Single Sign-On (SSO) lohnt sich in der Regel für die meisten Unternehmen, da es die Authentifizierung vereinfacht und gleichzeitig Sicherheit und Produktivität erhöht. Die zentrale Anmeldung reduziert die Anzahl wiederholter Passwörter, die Wiederverwendung schwacher Anmeldedaten und den Aufwand für den Helpdesk durch Passwortzurücksetzungen. Zudem ermöglicht sie die einheitliche Durchsetzung von Richtlinien wie Multi-Faktor-Authentifizierung und bedingtem Zugriff für alle verbundenen Anwendungen.

Der anfängliche Einrichtungsaufwand und die Abhängigkeit von einem zuverlässigen Identitätsanbieter stellen zwar eine gewisse Herausforderung dar, die langfristigen Vorteile überwiegen jedoch in der Regel die Komplexität und die Kosten der Implementierung. Eine höhere Sicherheit, ein schnelleres Onboarding und Offboarding, eine bessere Transparenz der Compliance und eine reibungslosere Benutzererfahrung sind dabei unerlässlich.