--- id: CP-193 slug: sso-saml-openid-connect lang: de title: "SSO: SAML und OpenID Connect einfach erklärt" description: Ein einziges Konto öffnet mehrere Anwendungen dank eines Tokens. Was SAML und OpenID Connect tun und wie Beschäftigte den Fallen begegnen. canonical_url: https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/ markdown_url: https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, „SSO: SAML und OpenID Connect einfach erklärt“, Cyberpedia, 2026. https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/ (CC BY 4.0)" wing: 3 theme: control_access reflex: cr-025 schema: G3 updated: "2026-11-03" translations: de: https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/ fr: https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/ en: https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/ es: https://startbrain.io/cyberpedia/es/articles/sso-saml-openid-connect/ sources: - "n": 1 title: NIST Special Publication 800-63C publisher: NIST url: https://pages.nist.gov/800-63-3/sp800-63c.html accessed: "2026-11-03" - "n": 2 title: Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 3 title: Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1539/ accessed: "2026-11-03" - "n": 4 title: How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference accessed: "2026-11-03" - "n": 5 title: OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc accessed: "2026-11-03" - "n": 6 title: "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/001/ accessed: "2026-11-03" - "n": 7 title: SAML Security - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html accessed: "2026-11-03" - "n": 8 title: "Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1606/002/ accessed: "2026-11-03" - "n": 9 title: "SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC" publisher: NIST url: https://csrc.nist.gov/pubs/sp/800/63/c/4/final accessed: "2026-11-03" --- # SSO: SAML und OpenID Connect einfach erklärt Mit SSO (Single Sign-on, Einmalanmeldung) authentifiert man sich einmal bei einem Identitätsanbieter und erhält dann Zugang zu mehreren Anwendungen, ohne für jede ein eigenes Passwort anzulegen oder sich zu merken [1]. Die Beschäftigten geben ihre Zugangsdaten auf der Anmeldeseite des Unternehmens ein, und die Anwendungen erhalten einen Nachweis der Identität statt des Passworts. Zwei Protokolle dienen vor allem diesem Austausch: SAML und OpenID Connect (OIDC). Auf dem Bildschirm sind sie nicht zu sehen, doch ihre Tokens sind zu einem Ziel geworden: Wer das Token oder die Sitzung stiehlt, stiehlt den Zugang. ## In 30 Sekunden - Wo es vorkommt: bei jedem Öffnen einer Unternehmensanwendung, die auf die gemeinsame Anmeldeseite weiterleitet. - Was der Angreifer will: ein Token, ein Sitzungscookie oder eine Berechtigung für eine präparierte Anwendung, die ihm den Zugang öffnen, ohne dass er das Passwort kennt [2][3]. - Der Reflex: die Adresse der Anmeldeseite prüfen, die Zwei-Faktor-Authentifizierung für das Hauptkonto aktivieren, sich an einem gemeinsam genutzten Rechner abmelden und jede unerwartete Anmeldeaufforderung melden. - Falls es schon passiert ist: sofort die IT-Abteilung informieren und angeben, welche Seite geöffnet war und welche Berechtigung erteilt wurde. ## Direkte Fragen ### Was ist SSO? Ein einziges Konto, verwaltet von einem Identitätsanbieter, dient mehreren Anwendungen. Das NIST-Dokument zur Identitätsföderation beschreibt diesen Fall: Der Nutzer authentifiziert sich nicht direkt bei der Anwendung, sondern der Identitätsanbieter erzeugt eine Assertion, oft auf Anfrage der Anwendung [1]. Laut NIST entfällt dadurch die Notwendigkeit, für jeden Dienst gesonderte Zugangsdaten zu besitzen [1]. ### Worin unterscheiden sich SAML und OpenID Connect? SAML 2.0 ist ein Protokoll, mit dem Anwendungen ihren Nutzern SSO anbieten können; es tauscht Assertions zwischen dem Identitätsanbieter und der Anwendung aus [4]. OpenID Connect erweitert das Autorisierungsprotokoll OAuth 2.0 zu einem Authentifizierungsprotokoll, und das SSO läuft über ein Sicherheitstoken, das ID-Token genannt wird [5]. Das NIST nennt beide als Beispiele für Föderationsprotokolle, wobei die Assertion die Form eines OIDC-ID-Tokens oder einer SAML-Assertion hat [1]. ### Ist SSO weniger sicher als ein Passwort pro Anwendung? Es verschiebt das Risiko eher, als dass es es beseitigt. Beschäftigte müssen nicht mehr für jede Anwendung ein Passwort verwalten [1], aber ein einziges Konto öffnet mehrere Dienste: Übernimmt ein Angreifer es, sind alle Dienste, die es akzeptieren, gefährdet. Die Fallen weiter unten gehen darauf näher ein. ### Was schützt die Zwei-Faktor-Authentifizierung, und was nicht? Sie schützt die erste Anmeldung. Gegen ein bereits gestohlenes Token oder Cookie schützt sie nicht: Der direkte Zugriff per Token hebt die Wirkung eines zweiten Faktors auf [6], und Sitzungscookies können manche Protokolle der Multifaktor-Authentifizierung umgehen [3]. ## Wie es funktioniert Zwei Akteure tauschen Informationen aus: der Identitätsanbieter, der die Person authentifiziert, und die Anwendung, die dem vertraut, was er behauptet [4]. Das NIST nennt die Anwendung „Relying Party“ (vertrauende Partei) und bezeichnet die Nachricht des Identitätsanbieters, die sie über die Person informiert, als Assertion [1]. Bei SAML erklärt Microsoft, dass die Anwendung beim Identitätsanbieter eine Weiterleitungsadresse und eine Metadatenadresse registriert, über die sich der Signaturschlüssel beschaffen lässt [4]. Bei OIDC ruft die Anwendung außerdem ein öffentliches Konfigurationsdokument ab, das die nötigen Adressen und die öffentlichen Schlüssel zur Prüfung der Token-Signatur enthält [5]. Für SAML beschreibt OWASP eine Antwort, die die mit dem privaten Schlüssel des Identitätsanbieters digital signierte Assertion enthält [7]. Ein Token ist kein Passwort: Es bescheinigt eine bereits erfolgte Authentifizierung. Für SAML nennt MITRE eine Standardlebensdauer von einer Stunde, die sich im Token ändern lässt [8]. In der Fassung 2017/2020 seiner Richtlinien, die inzwischen ersetzt wurde, ordnet das NIST Assertions drei Stufen zu. Auf der ersten ist die Assertion vom Identitätsanbieter signiert. Auf der zweiten ist sie zusätzlich für die Anwendung verschlüsselt. Auf der dritten weist der Nutzer zusätzlich nach, dass er einen an die Assertion gebundenen Schlüssel besitzt [1]. Die Fassung SP 800-63C-4 vom Juli 2025 ersetzt die vom 2. März 2020 [9]; diese drei Stufen sind also nicht die aktuelle Regel [1]. ## Was Sie tun - Prüfen Sie die Adresse der Anmeldeseite, bevor Sie ein Passwort eingeben. Angreifer fangen die Sitzung unterwegs ab, zum Beispiel mit den Werkzeugen evilginx2 und Muraena, die in Phishing-Kampagnen eingesetzt wurden [3]. - Aktivieren Sie die Zwei-Faktor-Authentifizierung für Ihr Hauptkonto, das die anderen Anwendungen öffnet. Wer den Zugang zum Haupt-Postfach kompromittiert, kann über das Verfahren „Passwort vergessen“ unter Umständen andere Dienste erreichen [6]. - Melden Sie sich an einem gemeinsam genutzten Rechner ab. Sitzungscookies bleiben oft lange gültig, selbst wenn die Anwendung nicht mehr benutzt wird [3]. Bei Microsoft beendet die Abmeldung die Sitzung des Nutzers [5]. - Lesen Sie das Fenster der Berechtigungsanfrage, bevor Sie klicken. Es fordert den Nutzer auf, einer Anwendung Berechtigungen zu erteilen [5]. - Melden Sie jede Anmelde- oder Berechtigungsanfrage, die Sie nicht selbst ausgelöst haben, vor allem nach einer Nachricht, die Sie zum Klick auf einen Link drängt: So lässt ein Angreifer seiner Anwendung den Zugang erteilen [2]. ## Die Fallen ### Gefälschte Anmeldeportale Die Open-Source-Frameworks evilginx2 und Muraena erbeuten Sitzungscookies über einen bösartigen Proxy zwischen dem Opfer und der echten Website [3]. Kali365 erlangte OAuth-Zugriffs- und Aktualisierungstokens, indem es Opfer dazu brachte, eine vom Angreifer gestartete Geräteautorisierungsanfrage zu bestätigen, und Sitzungen über eine Reverse-Proxy-Infrastruktur abfing [2]. ### Token- oder Sitzungsdiebstahl Zugriffstokens dienen dazu, im Namen eines Nutzers autorisierte Anfragen zu stellen [6]. Gestohlen ersetzen sie das Passwort: Die Gruppe APT29 nutzt gestohlene Tokens, um ohne Passwort auf Konten zuzugreifen [2]. Diese API-Zugriffe sind schwer zu erkennen, selbst auf Seiten des Anbieters, weil sie wie normale Nutzung aussehen [6]. Auch eine Passwortänderung reicht möglicherweise nicht aus, um sie zu unterbinden [6]. Aktualisierungstokens erlauben es, neue Tokens zu erhalten, ohne den Nutzer zu fragen [2]. ### Missbräuchliche OAuth-Einwilligungen Ein Angreifer registriert seine eigene Anwendung beim Autorisierungsserver und schickt dann einen Phishing-Link, damit das Opfer ihr Zugriff gewährt [2]. Sobald das Token erteilt ist, kann die Anwendung dauerhaften Zugriff auf das Konto erlangen, etwa um das Postfach zu durchsuchen und Kontakte aufzulisten [2][6]. Die Gruppe APT28 setzte als „Google Defender“, „Google Email Protection“ und „Google Scanner“ getarnte Anwendungen ein, um Gmail-Nutzer ins Visier zu nehmen [2]. ### Das Einzelkonto als Schwachstelle Wer ein gültiges SAML-Signaturzertifikat besitzt, kann Tokens mit selbst gewählten Rechten und beliebiger Lebensdauer fälschen und sich so bei allen Diensten authentifizieren, die SAML 2.0 für SSO nutzen [8]. MITRE nennt die Kompromittierung von SolarWinds, bei der die Gruppe APT29 Tokens mit kompromittierten SAML-Signaturzertifikaten erstellte [8]. ## Reale Fälle ### 2012: XML Signature Wrapping OWASP weist darauf hin, dass 2012 Schwachstellen in SAML-Implementierungen beschrieben wurden, die mit Angriffen durch XML Signature Wrapping zusammenhängen [7]. Zu den Empfehlungen gehört eine sichere Prüfung der digitalen Signatur [7]. Diese Aufgabe liegt bei den IT-Teams, nicht bei den Beschäftigten. ## Quellen 1. NIST, „NIST Special Publication 800-63C“. https://pages.nist.gov/800-63-3/sp800-63c.html (abgerufen am 3. November 2026) 2. MITRE ATT&CK, „Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®“. https://attack.mitre.org/techniques/T1528/ (abgerufen am 3. November 2026) 3. MITRE ATT&CK, „Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®“. https://attack.mitre.org/techniques/T1539/ (abgerufen am 3. November 2026) 4. Microsoft, „How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform“. https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference (abgerufen am 3. November 2026) 5. Microsoft, „OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform“. https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc (abgerufen am 3. November 2026) 6. MITRE ATT&CK, „Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®“. https://attack.mitre.org/techniques/T1550/001/ (abgerufen am 3. November 2026) 7. OWASP, „SAML Security - OWASP Cheat Sheet Series“. https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html (abgerufen am 3. November 2026) 8. MITRE ATT&CK, „Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®“. https://attack.mitre.org/techniques/T1606/002/ (abgerufen am 3. November 2026) 9. NIST, „SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC“. https://csrc.nist.gov/pubs/sp/800/63/c/4/final (abgerufen am 3. November 2026) --- Originalquelle: Cyberpedia, die öffentliche Enzyklopädie zu Cybersicherheit und KI von Brain. Kanonische Version: https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/ Sie dürfen diesen Text unter der Lizenz CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) frei weiterverwenden, sofern Sie „Brain, Cyberpedia“ mit einem Link auf die obige Adresse nennen.