Single Sign-On (SSO)
Single Sign-On (SSO) ist ein Anmeldeverfahren, mit dem sich ein Nutzer einmal zentral authentifiziert und danach ohne erneute Passworteingabe auf mehrere Anwendungen zugreift. Im ERP-Umfeld bedeutet das: eine Identität für ERP, Shop, Buchhaltung und weitere Systeme statt vieler getrennter Logins.
Single Sign-On (SSO) ist ein Authentifizierungsverfahren, bei dem sich ein Nutzer nur ein einziges Mal an einer zentralen Stelle anmeldet und anschließend auf alle angebundenen Anwendungen zugreifen kann, ohne sich dort erneut mit Benutzername und Passwort ausweisen zu müssen. Statt für ERP, Onlineshop, Buchhaltung, E-Mail und Projektwerkzeug je eigene Zugangsdaten zu pflegen, verwaltet ein zentraler Identitätsdienst die Anmeldung und bestätigt den anderen Systemen, dass der Nutzer bereits geprüft wurde.
Der praktische Kern von SSO ist die Trennung von Anmeldung und Anwendung: Nicht jedes einzelne Programm prüft das Passwort, sondern ein sogenannter Identity Provider übernimmt diese Aufgabe für alle. Die Fachanwendungen – im ERP-Kontext etwa das Warenwirtschaftssystem oder das angebundene Shopsystem – vertrauen dem Urteil dieses Dienstes. So sinkt die Zahl der Passwörter, die ein Mitarbeiter kennen muss, auf genau eines, während die IT die Zugänge an einer einzigen Stelle steuert.
Auf einen Blick
- Einmal zentral anmelden, danach ohne erneuten Login auf viele Systeme zugreifen
- Ein Identity Provider (IdP) authentifiziert, die Anwendungen (Service Provider) vertrauen ihm
- Verbreitete Standards: SAML 2.0, OAuth 2.0 und OpenID Connect
- Weniger Passwörter, weniger Passwort-Resets, zentrale Rechte- und Zugriffssteuerung
- Sicherheitsgewinn nur mit starker Absicherung des zentralen Zugangs (z. B. MFA)
Wie Single Sign-On funktioniert
SSO beruht auf einem Vertrauensverhältnis zwischen zwei Rollen. Der Identity Provider (IdP) ist der zentrale Dienst, der die Identität eines Nutzers prüft und verwaltet – etwa ein Verzeichnisdienst im Unternehmen oder ein Cloud-Login. Der Service Provider (SP) ist die eigentliche Anwendung, die der Nutzer benutzen will, zum Beispiel das ERP oder der Shop. Der Service Provider prüft das Passwort nicht selbst, sondern verlässt sich auf die Bestätigung des Identity Providers.
Ruft ein Nutzer eine geschützte Anwendung auf, ohne bereits angemeldet zu sein, leitet ihn die Anwendung an den Identity Provider weiter. Dort meldet er sich einmalig an. Der Identity Provider stellt daraufhin einen digital signierten Nachweis aus – ein Token oder eine Assertion –, der belegt: „Dieser Nutzer ist geprüft, er heißt X und darf Y.“ Die Anwendung prüft die Signatur, vertraut dem Nachweis und gewährt Zugriff. Für jede weitere angebundene Anwendung wiederholt sich dieser stille Abgleich, ohne dass der Nutzer sein Passwort erneut eintippt.
Die wichtigsten Protokolle: SAML, OAuth und OpenID Connect
Damit Identity Provider und Anwendungen herstellerübergreifend zusammenspielen, kommen offene Standards zum Einsatz. SAML 2.0 (Security Assertion Markup Language) ist ein etablierter, XML-basierter Standard, der vor allem im Unternehmensumfeld für den Austausch von Anmeldebestätigungen genutzt wird. OAuth 2.0 regelt eigentlich die Autorisierung, also die Frage, welche Zugriffe eine Anwendung im Namen des Nutzers erhält. OpenID Connect setzt als Identitätsschicht auf OAuth 2.0 auf und ergänzt es um die Authentifizierung – es ist heute der verbreitete Standard für web- und cloudbasierte Logins. Welches Protokoll passt, hängt vom Identity Provider und den anzubindenden Systemen ab.
Warum Single Sign-On wichtig ist: Nutzen und Grenzen
Der offensichtlichste Vorteil ist Bequemlichkeit: Ein Mitarbeiter merkt sich ein starkes Passwort statt vieler schwacher und spart sich das wiederholte Anmelden über den Arbeitstag. Für die IT entfällt ein Großteil der Passwort-Resets, die in vielen Support-Abteilungen zu den häufigsten Tickets zählen. Vor allem aber schafft SSO eine zentrale Steuerung: Verlässt ein Beschäftigter das Unternehmen, sperrt ein einziger Handgriff im Identity Provider sämtliche Zugänge auf einmal – ein erheblicher Sicherheits- und Compliance-Gewinn gegenüber verstreuten Einzel-Logins, die man leicht übersieht.
SSO hat jedoch eine gefährliche Kehrseite: Wird das zentrale Konto kompromittiert, steht dem Angreifer potenziell die gesamte Systemlandschaft offen. Der zentrale Zugang wird damit zum bevorzugten Angriffsziel. Deshalb gilt SSO fachlich nur dann als Sicherheitsgewinn, wenn die zentrale Anmeldung selbst stark abgesichert ist – in der Regel durch Mehr-Faktor-Authentifizierung (MFA), bei der zusätzlich zum Passwort ein zweiter Faktor wie ein Einmalcode oder eine App-Bestätigung nötig ist. SSO ohne MFA verlagert Risiko nur, statt es zu senken.
Single Sign-On im ERP-System
Ein ERP steht selten allein: Rund um das Warenwirtschaftssystem gruppieren sich Shop, PIM, Buchhaltung, CRM und weitere Werkzeuge. Genau in dieser Systemlandschaft entfaltet SSO seinen Wert. Bindet man das ERP über SAML oder OpenID Connect an den zentralen Identity Provider an, arbeitet das Team mit einer einzigen Identität über alle Anwendungen hinweg. Rollen und Rechte lassen sich zentral zuordnen, und neue Mitarbeitende erhalten mit einem Konto zugleich die passenden Zugriffe auf mehrere Systeme.
Viele Cloud-ERP-Systeme und SaaS-Lösungen unterstützen SSO ab bestimmten Tarifen von Haus aus, während On-Premise- oder ältere Systeme mitunter zusätzliche Konfiguration oder eine Middleware benötigen. Bei mandantenfähigen Systemen ist zusätzlich zu klären, wie Identitäten je Mandant getrennt bleiben. Technisch verwandt, aber nicht identisch ist die Anbindung über eine API oder REST-API: Diese regelt den maschinellen Datenaustausch zwischen Systemen, während SSO die Anmeldung menschlicher Nutzer betrifft. In der Praxis ergänzen sich beide innerhalb einer sauberen Integration.
Abgrenzung: SSO, Passwortmanager und Federation
Single Sign-On wird oft mit einem Passwortmanager verwechselt, doch beide lösen das Problem unterschiedlich. Ein Passwortmanager speichert weiterhin für jede Anwendung ein eigenes Passwort und füllt es nur bequem automatisch aus – die Vielzahl der Zugangsdaten bleibt bestehen. Bei echtem SSO existiert dagegen nur eine einzige Anmeldung, und die Fachanwendungen kennen gar kein separates Passwort mehr, sondern vertrauen dem zentralen Nachweis.
Ein weiterer Begriff ist Federation (föderierte Identität). Sie beschreibt SSO über Organisationsgrenzen hinweg: Ein Nutzer meldet sich beim Identity Provider seines eigenen Unternehmens an und erhält dennoch Zugriff auf die Anwendung eines Partners oder Cloud-Anbieters, weil beide Organisationen ein Vertrauensverhältnis vereinbart haben. Klassisches SSO wirkt innerhalb einer Organisation, Federation dehnt dasselbe Prinzip auf mehrere aus – technisch beruhen beide auf denselben Standards wie SAML oder OpenID Connect.
SSO und DSGVO: Datenschutz im DACH-Raum
Weil SSO personenbezogene Anmeldedaten zentral bündelt und häufig über Cloud-Dienste läuft, ist der Datenschutz früh mitzudenken. Nutzt man einen externen Identity Provider, dessen Server außerhalb der EU stehen, greifen die Vorgaben der DSGVO zur Auftragsverarbeitung und zum Drittlandtransfer. Zu klären sind ein Auftragsverarbeitungsvertrag, der Serverstandort und die Frage, welche Nutzerattribute überhaupt an die angebundenen Anwendungen übertragen werden – hier gilt das Prinzip der Datenminimierung.
Im Unternehmensalltag empfiehlt es sich, nur die tatsächlich nötigen Attribute (etwa Name, Rolle, Kennung) zu übermitteln und Anmeldevorgänge revisionssicher zu protokollieren, um im Prüfungsfall nachweisen zu können, wer wann Zugriff hatte. Für regulierte Branchen und öffentliche Stellen im DACH-Raum liefern die Empfehlungen des BSI eine praktische Orientierung, wie zentrale Authentifizierung sicher zu betreiben ist. So wird SSO nicht nur bequemer, sondern auch datenschutzkonform.
Praxisbeispiel
Beispiel: Ein Onboarding-Tag im Handelsunternehmen
Ein mittelständischer Onlinehändler beschäftigt 60 Mitarbeitende, die je nach Rolle ERP, Shop-Backend, Buchhaltung und ein CRM nutzen. Früher musste die IT für jede neue Person vier bis fünf Konten von Hand anlegen – und beim Ausscheiden ebenso viele wieder deaktivieren, wobei regelmäßig ein Zugang übersehen wurde.
Seit der Einführung von SSO läuft alles über einen zentralen Identity Provider. Am ersten Arbeitstag legt die IT genau ein Konto an, weist die Rolle „Kundenservice“ zu und die neue Kollegin erreicht damit sofort alle für sie freigegebenen Systeme – abgesichert mit einer App-basierten Zwei-Faktor-Bestätigung. Kündigt jemand, deaktiviert ein einziger Klick sämtliche Zugänge zeitgleich. Support-Tickets wegen vergessener Passwörter sind spürbar zurückgegangen.
Häufige Fragen
Passende ERP-Systeme
Passende Leistungen
Quellen
Fragen zu Single Sign-On (SSO) in deinem ERP-Projekt?
Wir beraten herstellerunabhängig – und setzen es auf Wunsch selbst um.