Cyberpediavon Brain
DEENFR

SSO: SAML und OpenID Connect einfach erklärt

Ein einziges Konto öffnet mehrere Anwendungen dank eines Tokens. Was SAML und OpenID Connect tun und wie Beschäftigte den Fallen begegnen.

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 kennt23.
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.

Worum es geht

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 merken1. 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.

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 Anwendung1. Laut NIST entfällt dadurch die Notwendigkeit, für jeden Dienst gesonderte Zugangsdaten zu besitzen1.

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 aus4. OpenID Connect erweitert das Autorisierungsprotokoll OAuth 2.0 zu einem Authentifizierungsprotokoll, und das SSO läuft über ein Sicherheitstoken, das ID-Token genannt wird5. Das NIST nennt beide als Beispiele für Föderationsprotokolle, wobei die Assertion die Form eines OIDC-ID-Tokens oder einer SAML-Assertion hat1.

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 verwalten1, 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 auf6, und Sitzungscookies können manche Protokolle der Multifaktor-Authentifizierung umgehen3.

1Wie es funktioniert1 min

Zwei Akteure tauschen Informationen aus: der Identitätsanbieter, der die Person authentifiziert, und die Anwendung, die dem vertraut, was er behauptet4. Das NIST nennt die Anwendung „Relying Party“ (vertrauende Partei) und bezeichnet die Nachricht des Identitätsanbieters, die sie über die Person informiert, als Assertion1.

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ässt4. 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ält5. Für SAML beschreibt OWASP eine Antwort, die die mit dem privaten Schlüssel des Identitätsanbieters digital signierte Assertion enthält7.

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ässt8.

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 besitzt1. Die Fassung SP 800-63C-4 vom Juli 2025 ersetzt die vom 2. März 20209; diese drei Stufen sind also nicht die aktuelle Regel1.

2Was Sie tun1 min
  • 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 wurden3.
  • 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 erreichen6.
  • Melden Sie sich an einem gemeinsam genutzten Rechner ab. Sitzungscookies bleiben oft lange gültig, selbst wenn die Anwendung nicht mehr benutzt wird3. Bei Microsoft beendet die Abmeldung die Sitzung des Nutzers5.
  • Lesen Sie das Fenster der Berechtigungsanfrage, bevor Sie klicken. Es fordert den Nutzer auf, einer Anwendung Berechtigungen zu erteilen5.
  • 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 erteilen2.
3Die Fallen2 min

Gefälschte Anmeldeportale

Die Open-Source-Frameworks evilginx2 und Muraena erbeuten Sitzungscookies über einen bösartigen Proxy zwischen dem Opfer und der echten Website3. 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 abfing2.

Token- oder Sitzungsdiebstahl

Zugriffstokens dienen dazu, im Namen eines Nutzers autorisierte Anfragen zu stellen6. Gestohlen ersetzen sie das Passwort: Die Gruppe APT29 nutzt gestohlene Tokens, um ohne Passwort auf Konten zuzugreifen2. Diese API-Zugriffe sind schwer zu erkennen, selbst auf Seiten des Anbieters, weil sie wie normale Nutzung aussehen6. Auch eine Passwortänderung reicht möglicherweise nicht aus, um sie zu unterbinden6. Aktualisierungstokens erlauben es, neue Tokens zu erhalten, ohne den Nutzer zu fragen2.

Missbräuchliche OAuth-Einwilligungen

Ein Angreifer registriert seine eigene Anwendung beim Autorisierungsserver und schickt dann einen Phishing-Link, damit das Opfer ihr Zugriff gewährt2. Sobald das Token erteilt ist, kann die Anwendung dauerhaften Zugriff auf das Konto erlangen, etwa um das Postfach zu durchsuchen und Kontakte aufzulisten26. Die Gruppe APT28 setzte als „Google Defender“, „Google Email Protection“ und „Google Scanner“ getarnte Anwendungen ein, um Gmail-Nutzer ins Visier zu nehmen2.

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 nutzen8. MITRE nennt die Kompromittierung von SolarWinds, bei der die Gruppe APT29 Tokens mit kompromittierten SAML-Signaturzertifikaten erstellte8.

4Reale Fälle1 min

2012: XML Signature Wrapping

OWASP weist darauf hin, dass 2012 Schwachstellen in SAML-Implementierungen beschrieben wurden, die mit Angriffen durch XML Signature Wrapping zusammenhängen7. Zu den Empfehlungen gehört eine sichere Prüfung der digitalen Signatur7. Diese Aufgabe liegt bei den IT-Teams, nicht bei den Beschäftigten.

Merkblatt

Kennung
CP-193
Flügel
3. Protokolle und Abwehr
Brain-Kompetenz
Zugriffe kontrollieren (control_access)
Brain-Reflex
cr-025
Schema
G3 · Anatomischer Schnitt
Sprachen
de, en, fr
Quellen
9 Quellen geprüft am 3. November 2026
Quellen9 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)

Diesen Artikel zitieren

Brain, „SSO: SAML und OpenID Connect einfach erklärt“, Cyberpedia, 2026. https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/

BibTeX 
@misc{brain_cp193_de_2026,
  author = {Brain},
  title = {SSO: SAML und OpenID Connect einfach erklärt},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/},
  note = {CC BY 4.0}
}
Lizenz CC BY 4.0