Wie Single Sign-On funktioniert
SSO beruht auf einer Vertrauensbeziehung zwischen zwei Parteien: einem Identity-Provider (IdP), der Nutzer authentifiziert und ihre Anmeldedaten verwahrt, und einem oder mehreren Service-Providern (SPs) — den Anwendungen, die der Nutzer erreichen möchte. Der Nutzer authentifiziert sich pro Sitzung genau einmal gegen den IdP; jede angebundene Anwendung akzeptiert dann das Wort des IdP als Identitätsnachweis.
Die Mechanik unterscheidet sich je nach Protokoll, doch die Grundform ist konsistent:
- Der Nutzer fordert Zugriff auf eine Anwendung an (den Service-Provider).
- Die Anwendung leitet den nicht authentifizierten Nutzer zum Identity-Provider um.
- Der IdP authentifiziert den Nutzer — Passwort, MFA, Passkey oder eine bestehende Sitzung — und stellt ein signiertes Token (OIDC) oder eine Assertion (SAML) aus.
- Die Anwendung validiert die Signatur gegen die veröffentlichten Schlüssel des IdP und gewährt Zugriff, ohne jemals das Passwort des Nutzers zu verarbeiten.
Da die Anwendung einer kryptografisch signierten Aussage des IdP vertraut, statt Anmeldedaten selbst zu prüfen, existiert das Passwort nur an einem einzigen Ort. Dies ist der zentrale Kompromiss von SSO: weniger Angriffsflächen für das Passwort, aber ein einziger, hochwertiger Vertrauenspunkt.
SAML 2.0 und OpenID Connect
Zwei Protokolle dominieren Enterprise-SSO. SAML 2.0 ist der ältere, XML-basierte Standard, gut etabliert für Webanwendungen und verbreitet in Business-to-Business- und Workforce-Szenarien. OpenID Connect ist eine moderne Identitätsschicht auf Basis von OAuth 2.0, die JSON Web Tokens (JWTs) über REST nutzt, und ist die Standardwahl für neuere Anwendungen, Mobile-Clients und API-getriebene Architekturen.
| SAML 2.0 | OpenID Connect (OIDC) | |
|---|---|---|
| Format | XML-Assertions | JSON Web Tokens (JWT) |
| Basiert auf | Eigenständiges XML-Rahmenwerk | OAuth 2.0 |
| Transport | Browser-POST/Redirect-Bindings | REST und HTTP, JSON-Payloads |
| Beste Passung | Web-SSO, etablierte Enterprise-Apps | Mobile, SPAs, APIs, modernes Web |
| Typische Nutzung | Workforce-SSO zu SaaS | Consumer-Login, delegierte Autorisierung |
Beide erreichen dasselbe Ergebnis — eine Authentifizierung, viele Anwendungen — und viele Identity-Provider unterstützen beide, sodass Legacy- und moderne Anwendungen sich einen einzigen Login teilen können.
Warum Organisationen SSO einführen
SSO ist eine der wirkungsvollsten Kontrollen im Identity and Access Management, aus Gründen, die sowohl sicherheits- als auch betriebsgetrieben sind:
- Weniger Passwörter, weniger schwache Passwörter. Nutzer merken sich eine starke Anmeldeinformation, statt ein schwaches Passwort über Dutzende Systeme hinweg wiederzuverwenden, was die Angriffsfläche für anmeldedatenbasierte Kompromittierung verkleinert.
- Zentralisierte Authentifizierungsrichtlinie. MFA, Passwortstärke, Sitzungsdauer und bedingter Zugriff werden einmal beim IdP durchgesetzt und gelten einheitlich für jede angebundene Anwendung.
- Schnelleres Onboarding und Deprovisioning. Das Deaktivieren eines einzigen IdP-Kontos entzieht den Zugriff auf jede angebundene Anwendung auf einmal — entscheidend, wenn ein Mitarbeiter das Unternehmen verlässt oder ein Konto kompromittiert ist. Ohne SSO bedeutet Deprovisioning, Konten in jedem System einzeln aufzuspüren.
- Sichtbarkeit über Zugriffe. Ein zentraler IdP erzeugt ein einziges Log von Authentifizierungsereignissen über die gesamte Anwendungslandschaft hinweg, statt fragmentierter Logs in jedem System.
Diese Vorteile sind der Grund, warum SSO eine Grunderwartung in der Enterprise-Sicherheit und eine gängige Anforderung in Compliance-Rahmenwerken ist.
Die Risiken und Grenzen von SSO
SSO konzentriert Vertrauen, und Konzentration schneidet in beide Richtungen. Dieselbe Architektur, die es einem deaktivierten Konto ermöglicht, jeglichen Zugriff zu entziehen, bedeutet auch, dass ein einziges kompromittiertes SSO-Konto alles freischalten kann, was damit verbunden ist. Wenn ein Angreifer die IdP-Anmeldedaten eines Nutzers phisht und MFA umgeht oder aushebelt, ist jede nachgelagerte Anwendung erreichbar. Das macht den Identity-Provider zum wertvollsten Ziel der Umgebung und ist der Grund, warum MFA, phishing-resistente Faktoren und bedingter Zugriff beim IdP nicht verhandelbar sind.
Die grundlegendere Grenze ist die des Geltungsbereichs. SSO regelt die Authentifizierung — wer hineinkommt — und nichts darüber hinaus. Sobald der IdP ein Token ausgestellt und eine Sitzung etabliert hat, hat SSO seine Aufgabe erfüllt und tritt zurück. Es sieht nicht, was der Nutzer innerhalb der Anwendung tut, auf welche Daten er zugreift, was er eingibt oder was eine Anwendung in seinem Auftrag tut. SSO sichert die Eingangstür; es hat keinen Einblick in die dahinterliegenden Räume.
Warum SSO für AI nicht ausreicht
Genau dieser auf die Eingangstür beschränkte Geltungsbereich ist der Punkt, an dem SSO in einer AI-getriebenen Umgebung zu kurz greift. SSO kann entscheiden, ob ein Nutzer ein freigegebenes AI-Tool öffnen darf. Es kann den Zugriff auf einen zugelassenen Chatbot, einen internen AI-Assistenten oder einen Coding-Copiloten hinter einem Unternehmens-Login absichern. Das ist wertvoll — es hält nicht zugelassene Identitäten fern und bindet die Nutzung an einen bekannten Nutzer.
Doch sobald die Sitzung läuft, ist SSO blind für alles, was beim AI-Risiko zählt:
- Es kann die Prompts, die ein Nutzer übermittelt, nicht sehen, sodass es nicht erkennen kann, ob eine Kundenliste oder ein vertraulicher Vertrag in das Modell eingefügt wird.
- Es kann die Completions, die das Modell zurückgibt, nicht prüfen, sodass es regulierte Daten nicht abfangen kann, die aus einem angebundenen System auftauchen.
- Es kann Agenten-Aktionen nicht steuern, sodass SSO, wenn ein AI-Agent ein externes Tool oder eine API im Auftrag des Nutzers aufruft, keine Aufzeichnung und keine Kontrolle hat.
- Es kann nicht unterscheiden, welches Modell oder welche Daten innerhalb eines autorisierten Tools im Spiel sind — jede Aktion innerhalb der Sitzung ist für SSO schlicht „ein authentifizierter Nutzer".
Mit anderen Worten: SSO beantwortet „Ist das ein legitimer Nutzer?", aber niemals „Ist das eine sichere AI-Aktion?" Authentifizierung ist notwendig, doch die AI-Aktivität nach der Authentifizierung ist der Ort, an dem Datenexposition, Prompt-Injection und ungesteuertes Agentenverhalten tatsächlich auftreten — und diese Aktivität ist für die Login-Schicht unsichtbar.
Fragen, die SSO beantwortet — und die, die es offenlässt
- Ist das ein legitimer, authentifizierter Nutzer? — Ja, SSO beantwortet dies direkt.
- Sollte dieser Nutzer dieses AI-Tool überhaupt öffnen dürfen? — Ja, über die Zugriffsrichtlinie des IdP.
- Was hat der Nutzer in dieser Sitzung an das AI-Modell übermittelt? — Nein. Außerhalb des Geltungsbereichs.
- Hat das Modell sensible Daten zurückgegeben, und an wen? — Nein. Außerhalb des Geltungsbereichs.
- Was hat ein AI-Agent getan, nachdem der Nutzer sich angemeldet hat? — Nein. Außerhalb des Geltungsbereichs.
Die ersten beiden sind Authentifizierungsfragen. Die letzten drei sind Governance-Fragen, die genau dort beginnen, wo SSO endet.
