Single Sign-On (SSO) ermöglicht es Benutzenden, sich einmal bei einem zentralen Identity-Anbieter zu authentifizieren und auf mehrere Anwendungen zuzugreifen, ohne die Anmeldeinformationen erneut eingeben zu müssen. SSO verhindert Password Fatigue, indem die Verantwortung für die Authentifizierung von einzelnen Anwendungen auf eine zentrale Stelle verlagert wird, die den authentifizierten Status gewährleistet.

Wenn Sie sich bei Ihrem Unternehmensnetzwerk authentifizieren und sofort auf Slack, GitHub oder eine interne Knowledge Base zugreifen können, ohne die Passwörter für jede Anwendung erneut eingeben zu müssen, erleben Sie SSO in Aktion.

Die SSO-Implementierung bietet sofortige und messbare Vorteile für Entwicklungs- und Security-Teams, da die Kontrolle zentralisiert und das Authentifizierungserlebnis standardisiert wird.

Zentralisierung von Sicherheit und Compliance

• Minimiert die Angriffsfläche: Durch die Zentralisierung der Authentifizierung auf ein einziges primäres Authentifizierungsereignis wird die Anzahl der Anmeldedaten reduziert, die Benutzende im gesamten Ökosystem aktiv verwalten müssen. Das hilft, die gesamte Angriffsfläche und das Kompromittierungsrisiko zu minimieren.
• Setzt konsistente Richtlinien durch: SSO hilft dabei, strenge Authentifizierungsrichtlinien wie Multi-Faktor-Authentifizierung (MFA) beim Identity-Anbieter durchzusetzen. Dadurch entfällt die Notwendigkeit, redundante Maßnahmen in Dutzenden Systemen zu implementieren.
• Vereinfacht die Überprüfbarkeit: Zentralisierte Authentifizierungsprotokolle beschleunigen die Erstellung von Audit-Trails und Compliance-Berichten und bieten Security-Teams eine zentrale Informationsquelle für Benutzerzugriffe im gesamten Anwendungs-Ökosystem.

Verbesserung der Geschwindigkeit und User Experience

• Eliminiert Redundanz: Für Entwicklungsteams entfällt durch SSO die Notwendigkeit, die Authentifizierungslogik in jeder neuen Anwendung zu implementieren und zu verwalten, sodass sie sich auf die Kernfunktionen konzentrieren können.
• Reduziert den Supportaufwand: Durch die Einführung von SSO wird die Anzahl der Helpdesk-Tickets für Passwortrücksetzungen und Account-Sperrungen minimiert, sodass sich die Supportteams auf wichtigere Probleme konzentrieren können.
• Beschleunigt die Provisionierung: Das Onboarding und die Deprovisionierung von Benutzenden werden vereinfacht, da der Zugriff auf mehrere Systeme durch eine einzige Aktion innerhalb des zentralen Identity-Systems gewährt oder entzogen wird.

SSO funktioniert über eine Reihe sicherer, Session-basierter Weiterleitungen, die auf einer kryptografischen Vertrauensbeziehung zwischen einer Anwendung (dem Service Provider) und dem Identity-Anbieter basieren.

Der zentrale SSO-Flow

1. Erste Anfrage: Ein Benutzender versucht, auf eine geschützte Anwendung (Service Provider) zuzugreifen. Der Service Provider erkennt die nicht authentifizierte Anfrage und leitet den Browser des Benutzenden zum Login-Endpoint des Identity-Anbieter weiter.
2. Authentifizierung und Identity-Anbieter-Session: Der Benutzende authentifiziert sich beim Identity-Anbieter mit einer bevorzugten Methode (z. B. einem Passwort, Passkey oder biometrischen Daten). Der Identity-Anbieter validiert die Identität, etabliert eine authentifizierte Session und speichert einen sicheren Session-Identifikator (meist in einem HttpOnly-, Secure-, SameSite-Cookie).
3. Token-Ausstellung: Der Identity-Anbieter leitet den Benutzenden mit einem auf diese Anwendung zugeschnittenen Sicherheitsartefakt zurück zum Service Provider.

• Für Security Assertion Markup Language (SAML) 2.0, spezifiziert von OASIS, ist dieses Artefakt eine signierte XML-Assertion, die Benutzer-Identity-Claims enthält.
• Für OpenID Connect (OIDC), spezifiziert von der OpenID Foundation, beinhaltet dies den Austausch eines Autorisierungscodes gegen ein ID-Token und ein Access Token, zusammen mit einem optionalen Refresh Token, je nach Clienttyp und Bereichskonfiguration. Weitere Informationen zu diesem Unterschied finden Sie unter Authentifizierung und Autorisierung.

4. Zugriff gewährt: Der Service Provider validiert die Assertion oder das Token, indem er die Claims für Signatur, das Ablaufdatum (exp), Gültigkeit nicht vor (nbf), Aussteller (iss) und Zielgruppe (aud) überprüft und eine lokale Session für den Benutzenden einrichtet.

Nahtloser nachfolgender Zugriff

Wenn derselbe Benutzende in derselben Browser-Session auf eine zweite Anwendung zugreift, die demselben Identity-Anbieter vertraut:

1. Die zweite Anwendung erkennt die nicht authentifizierte Anfrage und leitet den Benutzenden an den Identity-Anbieter weiter.
2. Der Identity-Anbieter erkennt die bestehende authentifizierte Session sofort anhand seines Session-Cookies.
3. Der Identity-Anbieter stellt ein neues, anwendungsspezifisches Security Token aus, ohne den Benutzenden zur erneuten Authentifizierung aufzufordern.
4. Der Benutzende erhält nahtlosen Zugriff auf die zweite Anwendung.

Diese Wiederverwendung des zentralen Authentifizierungsereignisses ist die technische Grundlage für SSO.

Modernes SSO nutzt standardisierte Protokolle, die den Austausch von Identitäts- und Autorisierungsdaten regeln. Die Auswahl des richtigen Protokolls (oder oft die Unterstützung beider Protokolle) ist für die Flexibilität der Integration notwendig.

Protokoll	Token-Format	Primärer Anwendungsfall	Komplexität
SAML 2.0	XML-Assertions	Enterprise B2B Federation, Legacy-Systeme	Umfangreicher, erfordert X.509-Zertifikatsverwaltung für Signaturverifizierung und optionale Verschlüsselung, einschließlich Zertifikatsrotation und Ablaufüberwachung
OIDC	JSON Web Token (JWTs)	Moderne Web-, Mobil- und API-gestützte Anwendungen	Einfacher, RESTful und entwicklerfreundlicher

• OIDC ist die Identity-Ebene, die auf OAuth 2.0 basiert. Sie verwendet signierte JWTs für Identity-Claims in ID-Token und passt sich nativ den API-Architekturen an. Für neue, internetbasierte oder Mobilgeräte-Anwendungen ist OIDC mit dem Autorisierungscode-Ablauf und PKCE die aktuelle OAuth 2.0 Best Practice-Sicherheitsempfehlung.
• SAML 2.0 ist nach wie vor für die B2B-Föderation weit verbreitet, insbesondere bei der Integration in die Customer Identity-Infrastruktur wie Active Directory-Verbunddienste (AD FS), da dies für große Unternehmen oft eine obligatorische Anforderung ist.

In einem B2B-SaaS-Kontext muss die Anwendung oft beide Protokolle unterstützen, da der Identity-Anbieter des Kundenunternehmens die Integrationsanforderungen vorgibt.

In B2B-SaaS-Umgebungen erfordert Multi-Tenant-SSO, dass eine Anwendung (der Service Provider) mit dem unabhängigen Identity-Anbieter jedes Kundenunternehmens verbunden ist.

• Tenant-spezifische Konfiguration: Eine Anwendung muss eindeutige Identity-Anbieter-Konfigurationsmetadaten (wie SAML-Signaturzertifikate oder OIDC-Client-Secrets) für jedes Kundenunternehmen sicher speichern und verwalten.
• Home Realm Discovery (HRD): Die Anwendung muss feststellen, welcher Identity-Anbieter des Kundenunternehmens für die Weiterleitung der Authentifizierungsanfrage verwendet werden soll. Dies wird in der Regel erreicht, indem die Anwendung basierend auf der E-Mail-Domain des Benutzenden oder einer vor dem Login eingegebenen Organisationskennung weitergeleitet wird.
• Just-In-Time (JIT)-Bereitstellung: JIT erstellt während der ersten SSO-Authentifizierung automatisch das lokale Konto des Benutzenden in der Anwendung, basierend auf Claims, die vom Identity-Anbieter eingegangen sind. Dadurch entfällt die manuelle Provisionierung von Benutzer-Accounts für Unternehmensbenutzer.
• Autorisierung nach der Authentifizierung: Nach erfolgreicher SSO-Authentifizierung muss eine Anwendung Autorisierungsrichtlinien wie rollenbasierte Zugriffskontrolle (RBAC) durchsetzen, um zu bestimmen, auf welche Ressourcen der Benutzende zugreifen kann. SSO bestätigt die Identität und die Autorisierungsebene der Anwendung kontrolliert die Berechtigungen.

SSO zentralisiert zwar die Authentifizierung, konsolidiert aber das Risiko. Entwicklungsteams müssen sicherstellen, dass der Service Provider gegen Token-bezogene Sicherheitslücken abgesichert ist.

• Zwingende Token-Validierung: Jeder geschützte API-Endpoint muss eine vollständige JWT-Validierung durchführen. Dazu gehören die Überprüfung der Signaturintegrität, die Überprüfung des exp-Claims sowie die Bestätigung der iss- und aud-Claims, um sicherzustellen, dass das Token authentisch und für Ihre Anwendung bestimmt ist.
• Sicherer Speicher: Vermeiden Sie die Speicherung vertraulicher Access Token oder Refresh Token in localStorage oder sessionStorage, da dies ein erhöhtes Risiko für Cross-Site Scripting (XSS) darstellt. Verwenden Sie für Single-Page-Anwendungen die Speicherung im Arbeitsspeicher mit automatischer Aktualisierung. Verwenden Sie für klassische Web-Apps HttpOnly- und Secure-Cookies mit SameSite-Flags.
• PKCE für OIDC: Verwenden Sie immer den Autorisierungscode-Ablauf mit Proof Key for Code Exchange (PKCE) für alle OIDC-basierten Anwendungen, einschließlich Mobil- und Web-Anwendungen, um Angriffe durch das Abfangen von Autorisierungscodes abzuwehren.
• Kurzlebige Token: Verwenden Sie kurzlebige Access Token (mit einer maximalen Dauer von 15–60 Minuten) und implementieren Sie eine Refresh Token-Rotation. Jeder Aktualisierungsvorgang gibt ein neues Refresh Token aus und macht das vorherige ungültig, sodass Token-Diebstahl sofort erkannt werden kann.
• Verhinderung der Session-Fixierung: Nach der Validierung des Identity-Anbieter-Tokens muss der Service Provider seine lokale Session-ID sofort regenerieren, um Session-Fixierungsangriffe zu verhindern. Das liegt in der Verantwortung des Service Providers (nicht des Identity-Anbieters).

Unsichere Service Provider-Session-Verwaltung

Service Provider validieren das Identity-Anbieter-Token oft korrekt, versäumen es aber, ihre eigene Anwendungssession abzusichern. Nach der SSO-Authentifizierung muss der Service Provider eine sichere Session mit angemessenem Timeout, CSRF-Schutz und sicheren Cookie-Flags einrichten.

Unzureichende Richtlinien für die Token-Lebensdauer

Das Akzeptieren langlebiger Identity-Anbieter-Sessions (über 24 Stunden) ohne erneute Authentifizierung birgt Risiken. Implementieren Sie angemessene Session-Timeouts und fordern Sie vor riskanten Aktionen mithilfe der Step-up-Authentifizierung zur erneuten Authentifizierung auf.

Ignorieren der Logout-Komplexität

Die SSO-Abmeldung erfordert die Koordination zwischen dem Identity-Anbieter und allen aktiven Service Providern. Bei unvollständigen Implementierungen sind Sessions in einigen Anwendungen nach dem Abmelden noch aktiv, wodurch ein falsches Sicherheitsgefühl entsteht. Implementieren Sie entweder eine zentrale Abmeldung (Single-Logout/SLO) oder eine klare Kommunikation des Session-Verhaltens.

Vertrauen auf Identity-Anbieter-Assertions ohne Validierung

Service Provider müssen jede Token-Signatur sowie alle Claims für Ablaufdatum, Zielgruppe und Aussteller validieren. Wenn die Validierung übersprungen wird, weil die Anfrage von einem bekannten Identity-Anbieter kam, stellt das eine Sicherheitslücke dar, die Angreifer mit Token-Fälschung oder Replay-Angriffen ausnutzen können.

Wie funktioniert SSO mit mobilen Anwendungen?

SSO auf Mobilgeräten verwendet das OIDC-Protokoll mit dem Autorisierungscode-Ablauf und PKCE. Es erfordert den Systembrowser (ASWebAuthenticationSession auf iOS, Custom Tabs auf Android) statt eingebetteter Webviews. Der Systembrowser gibt das Session-Cookie des Identity-Anbieters an Apps weiter, die dieselbe Authentifizierungsdomain verwenden, wodurch echtes SSO ermöglicht wird. Das Verhalten bei der gemeinsamen Session-Nutzung variiert jedoch je nach Plattform und Datenschutzeinstellungen. ASWebAuthenticationSession (in iOS) erstellt standardmäßig kurzlebige Sessions, bei denen Benutzende die Session-Persistenz explizit aktivieren müssen. Eingebettete Webviews können nicht auf den Cookie-Speicher des Systems zugreifen und das SSO-Erlebnis unterbrechen.

Ist SSO ein Ersatz für die Multi-Faktor-Authentifizierung (MFA)?

Nein. SSO bestimmt, wo die Authentifizierung stattfindet (bei einem zentralen Identity-Anbieter). MFA bestimmt die Stärke der Authentifizierung. Unternehmen sollten beides kombinieren: Setzen Sie MFA beim zentralen Identity-Anbieter durch, sodass eine einzige starke Authentifizierung den Zugriff auf alle verbundenen Anwendungen schützt.

Wann ist SSO nicht die richtige Wahl?

Bei kleinen Consumer-Apps oder Websites mit einfachen Inhalten überwiegen die Komplexität und die Infrastrukturanforderungen von SSO oft die Vorteile. SSO bietet maximalen Nutzen in Unternehmensumgebungen mit zentralisiertem IT-Management, in denen Benutzende einheitlichen Zugriff auf mehrere sichere Ressourcen benötigen.

Die Implementierung von SSO von Grund auf, insbesondere die Unterstützung von SAML und OIDC, ist ein komplexes Unterfangen. Eine dedizierte Identity-Plattform wie Auth0 kann die Protokollkomplexität, das Session-Management und die Absicherung übernehmen, sodass sich Entwicklungsteams auf die Kernfunktionen der Anwendung konzentrieren können.

In unserer Reihe „Einführung in IAM“ finden Sie weitere Informationen zu Identity and Access Management (IAM).

Mehr erfahren