Single Sign-On löst ein sehr konkretes Problem: zu viele Anwendungen, zu viele Kennwörter und zu viele Einzellogins. Wer Identität und Zugriff sauber organisieren will, braucht einen zentralen Anmeldepunkt, eine klare Rollenlogik und eine Technik, die Komfort nicht gegen Sicherheit eintauscht. In diesem Artikel erkläre ich, wie SSO funktioniert, welche Protokolle in der Praxis wichtig sind, wo die Grenzen liegen und wie ich eine Einführung in einer IAM-Landschaft aufbaue.
Die wichtigsten Punkte auf einen Blick
- SSO bündelt die Anmeldung an einem zentralen Identity Provider, der Zielanwendungen vertrauen.
- Die Technik vereinfacht den Zugriff, ersetzt aber weder Berechtigungen noch Mehrfaktor-Authentifizierung.
- Für moderne Apps ist OpenID Connect meist die pragmatischste Wahl, SAML bleibt in vielen Enterprise-Umgebungen relevant.
- SSO spart Reibung im Alltag und reduziert Supportaufwand, erhöht aber auch die Abhängigkeit vom Identity-System.
- Eine saubere Einführung braucht App-Inventar, Protokollwahl, Rollenmodell, Zertifikats- und Notfallplanung.
Wie Single Sign-On den Zugriff vereinfacht
NIST beschreibt SSO als einen Prozess, bei dem ein Konto und seine Anmeldedaten mehrere Anwendungen nahtlos erreichbar machen. Der wichtige Punkt ist für mich immer derselbe: SSO zentralisiert die Authentifizierung, nicht automatisch die Autorisierung. Ob ein Nutzer eine Funktion sehen darf, entscheidet weiterhin die Zielanwendung oder das zentrale Berechtigungsmodell.
Der typische Ablauf ist schlicht, aber technisch sauber:
- Der Nutzer öffnet eine Anwendung.
- Die Anwendung leitet zum Identity Provider weiter.
- Der Identity Provider prüft die vorhandene Sitzung oder fordert eine Anmeldung an.
- Nach erfolgreicher Prüfung sendet er eine signierte Bestätigung zurück, zum Beispiel eine Assertion oder ein Token.
- Die Anwendung akzeptiert diesen Nachweis und gibt den Zugriff frei.
Im Alltag bedeutet das weniger Reibung: Eine erneute Passwortabfrage fällt aus, solange die Sitzung gültig bleibt. Genau deshalb ist SSO so eng mit Identity-Provider-Architekturen, Sessions, Tokens und Federation verbunden. Damit die Abgrenzung im Betrieb nicht verwässert, lohnt der nächste Blick auf MFA und Passwortmanager.
SSO, MFA und Passwortmanager sind nicht dasselbe
Ich trenne diese drei Bausteine in Projekten bewusst voneinander, weil sonst schnell falsche Erwartungen entstehen. SSO löst das Anmeldeproblem über mehrere Anwendungen hinweg, MFA erhöht die Sicherheit der Anmeldung, und ein Passwortmanager hilft beim Speichern oder Ausfüllen von Zugangsdaten. Das klingt ähnlich, ist aber funktional etwas völlig anderes.
| Baustein | Aufgabe | Was er nicht ersetzt | Praktische Folge |
|---|---|---|---|
| SSO | Ein Login für mehrere Anwendungen | Berechtigungen und Freigaben | Weniger Passwortabfragen, zentraler Zugriff |
| MFA | Zusätzlichen Nachweis beim Login | SSO selbst | Mehr Schutz gegen kompromittierte Passwörter |
| Passwortmanager | Passwörter speichern und ausfüllen | Zentrale Zugriffssteuerung | Hilft Nutzern, ersetzt aber keine IAM-Architektur |
| Autorisierung | Regelt, was jemand tun darf | Identitätsprüfung | Ohne saubere Rollen bleibt SSO nur bequemer Login |
Gerade dieser Unterschied wird oft unterschätzt. Ein Passwortmanager kann die Bedienung verbessern, aber er schafft keine Föderation zwischen Systemen. Und MFA macht einen schwachen Zugriffspfad nicht automatisch sauber, wenn Rollen, Lebenszyklen und Protokolle ungeordnet bleiben. Wenn diese Rollen sauber getrennt sind, wird die Protokollfrage deutlich einfacher.
Welche Protokolle in der Praxis zählen
Für neue Integrationen ist die Protokollwahl oft der eigentliche Designentscheid. Microsoft Entra führt für Cloud-Anwendungen vor allem OpenID Connect, OAuth, SAML sowie in bestimmten Fällen password-based oder linked SSO auf. In der Praxis greife ich für moderne Web- und Mobile-Anwendungen meist zuerst zu OIDC, für etablierte Enterprise-Apps oft zu SAML.
| Verfahren | Wofür es sich eignet | Stärke | Grenze |
|---|---|---|---|
| SAML 2.0 | Traditionelle Web-Apps und Föderation zwischen Organisationen | Reif, weit verbreitet, stark bei Attributen | XML-lastig und für moderne App-Stacks oft schwerfälliger |
| OpenID Connect | Moderne Web-, Mobile-Apps und APIs | Schlank, tokenbasiert, gut mit aktuellen Frameworks | Braucht ein sauberes OAuth/OIDC-Design |
| Password-based SSO | Legacy-Apps mit HTML-Login oder geteilten Konten | Schnelle Übergangslösung ohne tiefen Eingriff in die App | Bleibt ein Vault- oder Replay-Ansatz, keine echte Föderation |
| Linked SSO | Migrationsphasen und Portale | Schnell nutzbar, gute Zwischenstufe | Kein echtes Sign-in über den IdP |
| Integrated Windows Authentication | Interne Windows- und On-Premises-Umgebungen | Sehr bequem im Unternehmensnetz | An Plattform, Netzwerk und Browser-Situation gebunden |
Wichtig ist die Unterscheidung zwischen OAuth 2.0 und OIDC: OAuth ist für Autorisierung gedacht, nicht als Login-Standard. Erst OIDC ergänzt die Identitätsprüfung. Genau an dieser Stelle entstehen in vielen Architekturgesprächen die meisten Missverständnisse. Daraus ergeben sich dann die typischen Vorteile im Betrieb.
Warum Unternehmen SSO einsetzen
SSO lohnt sich vor allem dort, wo Menschen täglich zwischen vielen Anwendungen wechseln. Weniger Passwortwechsel bedeuten weniger Frust, und zentral gesteuerte Policies reduzieren die Zahl der Einzelsysteme, die eigene Login-Regeln pflegen müssen. In Betriebsumgebungen senkt das in der Regel auch den Ticketdruck im Helpdesk, weil Passwort-Resets, verwaiste Konten und Zugriffsfragen übersichtlicher werden.
- Einmal anmelden, mehrfach nutzen erhöht die Akzeptanz bei Mitarbeitern und Kunden.
- Zentrale Richtlinien machen MFA, Conditional Access und Sperrungen konsistenter.
- Schnelleres Onboarding und Offboarding reduziert Schattenkonten und manuelle Nacharbeit.
- Bessere Nachvollziehbarkeit entsteht, weil der IdP ein zentraler Kontrollpunkt ist.
Für Unternehmen mit vielen SaaS-Diensten ist SSO deshalb nicht nur Komfort, sondern ein Hebel für Governance. Und genau an dieser Stelle tauchen auch die Grenzen auf, die man vor dem Rollout kennen sollte.
Wo SSO an Grenzen stößt
Die größte Schwäche von SSO ist die Zentralisierung selbst. Wenn der Identity Provider ausfällt, sind potenziell viele Anwendungen betroffen. Wenn ein zentrales Konto kompromittiert wird, ist der Schaden größer als bei einem isolierten System. Deshalb ist SSO ohne MFA, saubere Rollen und Monitoring nur halb fertig.
- Ein Ausfall des IdP kann wie ein Dominoeffekt wirken.
- Abmeldung ist nicht immer gleich Abmeldung - Sessions in Zielsystemen können länger leben als die IdP-Sitzung.
- Legacy-Apps unterstützen Föderation oft nur eingeschränkt.
- Passwortbasiertes SSO ist eher Übergang als Zielbild.
- Zu viele Attribute in Assertions oder Claims machen Integrationen unnötig fragil.
Ich plane deshalb immer mit Hochverfügbarkeit, einem Fallback-Pfad und dem Prinzip der kleinsten Rechte. Besonders kritisch sind gemeinsam genutzte Konten, weil sie Verantwortlichkeiten verwischen und oft nur mit Übergangslösungen sauber nutzbar sind. Deshalb gehört SSO nie isoliert betrachtet, sondern immer als Teil der gesamten IAM-Architektur.
Wie ich eine SSO-Einführung aufbaue
Eine gute Einführung beginnt nicht mit dem Tool, sondern mit dem Anwendungsbestand. Ich prüfe zuerst, welche Systeme SAML oder OIDC sprechen, welche nur passwortbasierte Übergänge vertragen und welche intern per Windows-Integration oder Proxy angebunden werden müssen. Danach lege ich fest, welche Claims, Gruppen und Rollen wirklich gebraucht werden - nicht mehr, weil jedes zusätzliche Attribut Komplexität und Angriffsfläche erhöht.
- Applikationen klassifizieren. Cloud, On-Premises, Hybrid, Legacy und Systeme mit geteilten Konten gehören getrennt betrachtet.
- Protokoll wählen. OIDC für moderne Apps, SAML für bestehende Enterprise-Integrationen, Übergangslösungen nur dort, wo es keine bessere Option gibt.
- MFA und Richtlinien festziehen. SSO ohne starke zweite Stufe ist zu leicht angreifbar.
- Zertifikate und Schlüssel planen. Für SAML sollte der Zertifikatswechsel nicht zum Last-minute-Thema werden; in Microsoft Entra beträgt die Standardlaufzeit eines solchen Zertifikats 3 Jahre.
- Pilotieren und protokollieren. Erst kleine Benutzergruppen, dann Rollout, begleitet von Sign-in-Logs und klaren Support-Pfaden.
- Deprovisioning mitdenken. Wer ausscheidet, darf nicht nur im IdP gesperrt werden, sondern auch in Zielsystemen sauber entfernt werden.
Besonders wichtig ist mir außerdem der Umgang mit Notfallzugängen. Ein SSO-System braucht Break-glass-Konten, dokumentierte Wiederanlaufwege und einen klaren Ablauf für Zertifikatsrotation und Rollback. Genau hier trennt sich ein sauberer Enterprise-Ansatz von einer bloßen Demo-Integration.
Was ich bei SSO-Projekten zuerst prüfe
- Kann die Zielanwendung echtes SSO über SAML oder OIDC, oder brauche ich nur eine Übergangslösung?
- Sind MFA, Conditional Access und Rechtevergabe konsistent definiert?
- Gibt es einen Plan für Zertifikate, IdP-Ausfall, Logout und Support?
Wenn diese drei Fragen sauber beantwortet sind, wird SSO in der Regel kein Zusatzproblem, sondern ein stabiler Baustein für Identität und Zugriff. Genau so setze ich es in reifen Umgebungen auf: zentral, nachvollziehbar und mit genug Disziplin für die Fälle, in denen der bequeme Teil kurz ausfällt.
