Single Sign-on (SSO): Definition, Funktionsweise und Einsatz in der Unternehmens-IT

Single Sign-on (SSO) ist ein Anmeldeverfahren, bei dem sich Benutzer einmal bei einem zentralen Identitätsdienst authentifizieren und danach ohne erneute Eingabe ihrer Zugangsdaten auf mehrere Anwendungen zugreifen. Den Nachweis der Identität übernimmt der Identity Provider (IdP). Er stellt nach der Anmeldung ein signiertes Token aus, dem die angebundenen Anwendungen vertrauen. Das NIST beschreibt SSO als Verfahren, das in der Regel über ein Föderationsprotokoll umgesetzt wird.

In Unternehmen mit Dutzenden von Cloud- und On-Premises-Anwendungen ist SSO weniger eine Komfortfunktion als ein Steuerungsinstrument. Anmelderegeln wie Multi-Faktor-Authentifizierung gelten an einer Stelle, und ein gesperrtes Konto kann sich bei keiner föderierten Anwendung mehr neu anmelden. Damit das im Alltag funktioniert, braucht es neben der Technik feste Serviceprozesse für Anbindung, Änderungen und Austritte.

Das Wichtigste in Kürze

• Prinzip: Eine Anmeldung beim IdP, danach Token für die angebundenen Anwendungen. Beim föderierten SSO sieht die Anwendung das Kennwort nicht.
• Protokolle: SAML 2.0 und OpenID Connect für Web- und Cloud-Anwendungen, Kerberos im Windows-Netz. OAuth 2.0 regelt die Autorisierung, nicht die Anmeldung.
• Abgrenzung: SSO ersetzt weder MFA noch das Berechtigungsmanagement. Es bündelt die Anmeldung, sodass Schutzmaßnahmen an einer Stelle wirken.
• Betrieb: Der IdP wird zum kritischen System. Notfallzugänge, das Entziehen von Konten und klare Abläufe im Service Desk gehören zur Einführung.

Stand: November 2026 · Fachlich abgeglichen mit Microsoft Learn, den Spezifikationen von OASIS, OpenID Foundation und IETF sowie dem BSI IT-Grundschutz (Quellen am Ende des Artikels)

So funktioniert Single Sign-on

An jedem SSO-Vorgang sind drei Parteien beteiligt: die Person, die sich anmeldet, der Identity Provider (zum Beispiel Microsoft Entra ID, Okta oder ein selbst betriebenes Keycloak) und die Anwendung, die in der Fachsprache Service Provider oder Relying Party heißt. Zwischen IdP und Anwendung besteht eine vorab eingerichtete Vertrauensstellung, meist über ausgetauschte Metadaten und Signaturzertifikate.

Der Ablauf in fünf Schritten

1. Die Person ruft eine Anwendung auf, etwa das CRM-System im Browser.
2. Die Anwendung erkennt keine eigene Sitzung und leitet an den IdP weiter.
3. Der IdP prüft, ob bereits eine gültige Anmeldung besteht. Falls nicht, fragt er die Zugangsdaten ab und, je nach Richtlinie, einen zweiten Faktor oder den Gerätestatus.
4. Der IdP stellt eine signierte Bestätigung aus: bei SAML eine Assertion im XML-Format, bei OpenID Connect ein ID-Token im JSON-Web-Token-Format.
5. Die Anwendung prüft die Signatur, liest Attribute wie Name, E-Mail-Adresse oder Gruppen aus und legt eine eigene Sitzung an.

Öffnet die Person danach eine zweite Anwendung, entfällt Schritt 3, solange die Sitzung beim IdP gilt. Genau das ist der Effekt, den Benutzer als „einmal anmelden“ erleben.

SSO im Windows-Netz: Kerberos

Im lokalen Netz mit Active Directory beruht SSO auf Kerberos. Nach der Anmeldung an der Domäne erhält der Benutzer vom Domain Controller ein Ticket, mit dem er weitere Tickets für Dateifreigaben, Drucker oder Fachanwendungen bekommt, ohne sein Kennwort erneut einzugeben. Microsoft beschreibt Kerberos ausdrücklich als Teil der Windows-Anmeldearchitektur für einmaliges Anmelden.

In hybriden Umgebungen kommt die Cloud hinzu. Auf Geräten mit Windows 10 oder 11, die in Microsoft Entra ID oder hybrid eingebunden sind, sorgt das Primary Refresh Token (PRT) dafür, dass die Windows-Anmeldung auch für Microsoft 365 und andere Cloud-Anwendungen gilt. Für ältere, nur in die Domäne eingebundene Geräte gibt es das nahtlose SSO von Microsoft Entra.

Varianten, die ebenfalls „SSO“ heißen

• Kennwortbasiertes SSO: Der IdP speichert Benutzername und Kennwort einer Anwendung und gibt sie bei Bedarf weiter. Das hilft bei Anwendungen ohne Föderationsprotokoll, die Anwendung kennt dann aber weiterhin ein eigenes Kennwort.
• Verknüpftes SSO: Im Portal erscheint nur ein Link auf die Anwendung. Microsoft weist darauf hin, dass dies kein echtes einmaliges Anmelden ist.
• Social Login: „Mit Google anmelden“ und ähnliche Schaltflächen nutzen meist OpenID Connect mit einem Konto eines Plattformanbieters. Für Unternehmensanwendungen ist das in der Regel nicht das Ziel.

SAML, OpenID Connect und OAuth 2.0: die Unterschiede

SAML 2.0 und OpenID Connect lösen dieselbe Aufgabe: Ein IdP bestätigt einer Anwendung, wer sich angemeldet hat. Sie stammen aber aus unterschiedlichen Zeiten und passen zu unterschiedlichen Anwendungstypen. Microsoft ordnet OpenID Connect vor allem modernen Web- und Mobile-Anwendungen zu, SAML eher etablierten Unternehmensanwendungen.

Und OAuth 2.0?

OAuth 2.0 wird oft als SSO-Standard genannt, ist aber nach RFC 6749 ein Rahmen für die Autorisierung: Eine Anwendung erhält damit begrenzten Zugriff auf einen Dienst, etwa auf einen Kalender. Ein Access Token sagt der Anwendung nicht verlässlich, wer sich angemeldet hat. Diese Lücke schließt OpenID Connect, das auf OAuth 2.0 aufsetzt und ein eigenes ID-Token für die Anmeldung definiert.

SSO, MFA und IAM: drei verschiedene Dinge

• SSO legt fest, wie oft und wo sich jemand anmeldet: einmal, beim IdP.
• Multi-Faktor-Authentifizierung legt fest, wie stark diese Anmeldung abgesichert ist. Mit SSO genügt es, MFA am IdP durchzusetzen.
• Identity & Access Management (IAM) umfasst den gesamten Lebenszyklus: Konten anlegen, Rollen und Rechte vergeben, regelmäßig prüfen, beim Austritt entziehen.

SSO selbst legt in den Anwendungen keine Konten an und löscht keine. Dafür gibt es die Provisionierung, standardisiert etwa über SCIM (RFC 7644). Microsoft Entra ID kann darüber Konten in angebundenen Anwendungen automatisch anlegen und beim Austritt deaktivieren, sofern die Anwendung das unterstützt.

SSO in der Unternehmens-IT einführen und betreiben

Eine einzelne Anwendung an den IdP anzubinden, ist technisch meist überschaubar. Aufwendig wird es, wenn SSO für hundert Anwendungen und mehrere tausend Konten zuverlässig laufen soll. Dann entscheidet nicht die Technik, sondern die Standardisierung.

Fünf Schritte zur Einführung

1. Anwendungsinventar: Welche Anwendungen gibt es, welche Protokolle unterstützen sie, wer ist fachlich verantwortlich, wie kritisch sind die Daten?
2. Führende Identitätsquelle festlegen: In vielen Unternehmen bleibt Active Directory die Quelle und wird mit Microsoft Entra ID synchronisiert.
3. Standardmuster definieren: welche Attribute und Gruppen übergeben werden, wie Zuweisungen laufen, wer Zertifikate wechselt.
4. In Wellen migrieren: zuerst Anwendungen mit vielen Benutzern und wenig Sonderfällen, Altsysteme mit lokalen Konten zuletzt.
5. Betrieb übergeben: Zertifikatslaufzeiten überwachen, Änderungen über das Change Management steuern, Lösungswissen in der Knowledge Base dokumentieren.

Beispiel: SSO-Anbindung als Standardleistung im Servicekatalog

Angenommen, ein Handelsunternehmen mit 800 Mitarbeitenden führt pro Quartal zwei bis drei neue SaaS-Anwendungen ein. Ohne festen Ablauf verhandelt jede Fachabteilung die Anbindung selbst, es entstehen lokale Konten, und niemand weiß später, wer welche Gruppe freigegeben hat.

Mit einem Service Request „Anwendung an SSO anbinden“ erfasst die Fachabteilung Protokoll, Verantwortliche, benötigte Gruppen und Datenklassifizierung in einem Formular. Die Informationssicherheit gibt frei, das Identity-Team setzt die Anbindung als Standard-Change um, und die Konfiguration ist im Ticket dokumentiert.

Was der Service Desk über SSO wissen muss

Mit SSO ändern sich die typischen Tickets. Statt vergessener Kennwörter für einzelne Anwendungen geht es um fehlende Zuweisungen, Anmeldeschleifen im Browser oder ein neues Smartphone für den zweiten Faktor. Ein Sonderfall verdient eine eigene Lösung in der Wissensdatenbank: Läuft das Signaturzertifikat einer SAML-Anbindung ab, scheitern alle Benutzer dieser Anwendung gleichzeitig. Das ist ein Fall für das Incident Management mit hoher Priorität, nicht für Einzeltickets.

Wo eine ITSM-Software ansetzt

Eine ITSM-Software ersetzt keinen Identity Provider. Sie bündelt aber Anträge, Freigaben, Umsetzung und Störungen rund um SSO in nachvollziehbaren Abläufen. ky2help^® unterstützt im Standard Single Sign-on über Azure AD (heute Microsoft Entra ID) und eine Schnittstelle zu Active Directory (AD/LDAP). Zugangsanfragen laufen über Self-Service-Portale, und die Workflows lassen sich im Prozessdesigner per Drag-and-Drop ohne Programmierung anpassen.

Service Requests ansehen

Risiken und Best Practices

SSO verschiebt Risiken, es beseitigt sie nicht. Was bisher auf viele Anwendungen verteilt war, konzentriert sich am IdP. Der BSI IT-Grundschutz empfiehlt im Baustein ORP.4 einen zentralen, netzbasierten Authentisierungsdienst und sieht zugleich eine Notfallvorsorge für das Identitäts- und Berechtigungsmanagement vor.

Ausfall des Identity Providers

Ist der IdP nicht erreichbar, scheitern neue Anmeldungen an allen föderierten Anwendungen. Microsoft rät zu zwei oder mehr Notfallzugriffskonten. Das sollen reine Cloud-Konten sein, die weder im Verbund noch aus dem lokalen AD synchronisiert sind. Dazu gehört eine Liste der Anwendungen, die im Notfall lokal erreichbar bleiben müssen.

Ein Konto öffnet viele Türen

Ein kompromittiertes SSO-Konto gibt Angreifern Zugang zu allen angebundenen Anwendungen. Deshalb gehört MFA an den IdP, für Konten mit weitreichenden Rechten ohne Ausnahme. Auch ORP.4 empfiehlt für solche Konten eine Mehr-Faktor-Authentisierung (Anforderung A10). In Microsoft Entra ID lassen sich über Authentifizierungsstärken phishingresistente Verfahren wie FIDO2-Sicherheitsschlüssel vorschreiben.

Sperren wirkt nicht überall sofort

Ein deaktiviertes Konto kann sich nicht mehr neu anmelden. Bereits ausgestellte Token und Sitzungen in Anwendungen gelten aber bis zu ihrem Ablauf weiter. Zugriffstoken der Microsoft Identity Platform sind standardmäßig zwischen 60 und 90 Minuten gültig. Die fortlaufende Zugriffsevaluierung (CAE) verkürzt das für unterstützte Dienste wie Exchange Online, SharePoint Online und Teams auf nahezu Echtzeit, laut Microsoft mit bis zu 15 Minuten Verzögerung. Für Austritte mit sofortiger Wirkung gehören deshalb Kontosperre, Widerruf der Sitzungen und Deprovisionierung in denselben Ablauf.

Best Practices im Überblick

• Anwendungen nur über Gruppen zuweisen, nicht an einzelne Personen.
• Lokale Konten neben SSO, vor allem Administratorkonten, inventarisieren und gesondert absichern.
• Ablaufdaten von Signaturzertifikaten überwachen und den Wechsel als geplanten Change durchführen.
• Nur die Attribute an Anwendungen übergeben, die sie wirklich benötigen.
• Anmeldeprotokolle des IdP auswerten, aber nicht mit einem Protokoll der Tätigkeiten in der Anwendung verwechseln.

Häufige Fragen zu Single Sign-on

Was ist Single Sign-on einfach erklärt?

Single Sign-on bedeutet, dass sich eine Person einmal bei einem zentralen Identitätsdienst anmeldet und danach ohne weitere Kennworteingabe mehrere Anwendungen nutzt. Der Identitätsdienst bestätigt den Anwendungen über ein signiertes Token, dass die Anmeldung erfolgreich war.

Ist SSO sicherer als einzelne Passwörter?

SSO reduziert die Zahl der Kennwörter und erlaubt es, MFA und Anmelderegeln an einer Stelle durchzusetzen. Zugleich wird das zentrale Konto zum lohnenden Ziel. Sicherer wird SSO deshalb erst zusammen mit starker MFA, Notfallzugängen und einem festen Austrittsprozess.

Was ist der Unterschied zwischen SSO und MFA?

SSO regelt, dass eine Anmeldung für mehrere Anwendungen gilt. MFA regelt, wie diese Anmeldung abgesichert ist, nämlich mit mindestens zwei unabhängigen Faktoren. Beide ergänzen sich: Mit SSO muss MFA nur am Identity Provider eingerichtet werden.

Was ist der Unterschied zwischen SAML und OpenID Connect?

SAML 2.0 ist ein XML-basierter OASIS-Standard, der vor allem in etablierten Unternehmensanwendungen verbreitet ist. OpenID Connect baut auf OAuth 2.0 auf, nutzt JSON Web Tokens und wird für moderne Web- und Mobile-Anwendungen bevorzugt.

Was passiert mit SSO-Zugängen, wenn Mitarbeitende das Unternehmen verlassen?

Wird das Konto am Identity Provider deaktiviert, sind keine neuen Anmeldungen mehr möglich. Bestehende Sitzungen und Token laufen jedoch bis zu ihrem Ablauf weiter, und lokale Konten in Anwendungen bleiben bestehen. Ein vollständiger Austrittsprozess widerruft deshalb auch Sitzungen und entzieht Konten in den Anwendungen.

Unterstützt ky2help® Single Sign-on?

Ja. ky2help^® unterstützt im Standard Single Sign-on über Azure AD, heute Microsoft Entra ID, sowie eine Schnittstelle zu Active Directory (AD/LDAP). Wie das in Ihrer Umgebung aussieht, zeigen wir in einer Live-Demo.

Quellen und weiterführende Artikel

Quellen

• NIST CSRC: Glossar „Single Sign-On“
• Microsoft Learn: Was ist einmaliges Anmelden?
• OASIS: SAML V2.0 Technical Overview
• OpenID Foundation: OpenID Connect Core 1.0
• IETF: RFC 6749 – The OAuth 2.0 Authorization Framework und RFC 7644 – SCIM Protocol
• Microsoft Learn: Fortlaufende Zugriffsevaluierung
• BSI: IT-Grundschutz-Baustein ORP.4 Identitäts- und Berechtigungsmanagement (Edition 2022)

Weiterlesen im Glossar und in der Wissenswelt

• Multi-Faktor-Authentifizierung (MFA) und Authentifizierung
• Active Directory
• IT Service Management (ITSM)
• ITIL Anforderungsmanagement (Service Requests)
• Automatisierung von Routineaufgaben im ITSM