SAML vs. SSO: Die wichtigsten Unterschiede verstehen

Viele IT-Teams verwenden SAML und SSO synonym. In der Praxis bezeichnen sie jedoch zwei unterschiedliche Dinge – das eine ein Ziel, das andere ein Mechanismus, um dieses Ziel zu erreichen.

Single Sign-On (SSO) ist das Ergebnis für den Benutzer: eine Anmeldung, die den Zugriff auf mehrere Anwendungen ermöglicht. SAML (Security Assertion Markup Language) ist ein technisches Protokoll – eine der am weitesten verbreiteten Methoden, um dies zu realisieren, insbesondere in Unternehmensumgebungen.

Dieses Unterscheidungsmerkmal zu verstehen, ist mehr als nur ein technisches Detail. Ob Sie Unternehmensanwendungen bereitstellen, einen externen Identitätsanbieter integrieren oder Authentifizierungsoptionen für Ihr Unternehmen evaluieren – zu wissen, wo SAML in eine SSO-Strategie passt, hilft Ihnen, bessere Architektur- und Sicherheitsentscheidungen zu treffen.

SAML vs. SSO auf einen Blick

• SSO = das Ziel (Benutzer melden sich einmal an und können ohne wiederholte Authentifizierung auf mehrere Apps zugreifen)
• SAML = das Protokoll (Der technische Standard, der einen sicheren, föderierten Identitätsaustausch zwischen Systemen ermöglicht)
• Beziehung: SAML ist eine etablierte Methode zur Implementierung von SSO, insbesondere in Unternehmens- und B2B-Umgebungen.

Was ist SAML?

Security Assertion Markup Language (SAML) ist ein offener, XML-basierter Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen zwei Parteien: einem Identitätsanbieter (IdP) und einem Dienstanbieter (SP). Er wurde von der OASIS-Standardisierungsorganisation entwickelt; SAML 2.0 – die heute weit verbreitete Version – wurde 2005 veröffentlicht.

Im Kern funktioniert SAML SSO dadurch, dass der Identitätsanbieter (IdP) die Identität des Nutzers gegenüber dem Dienstanbieter (SP) mithilfe digital signierter XML-Dokumente, sogenannter SAML-Assertions, bestätigt. Der SP vertraut diesen Assertions, ohne jemals direkt mit den Anmeldeinformationen des Nutzers in Kontakt zu treten.

Hauptmerkmale von SAML

• XML-basiertes Token-Format für strukturierte, maschinenlesbare Identitätsansprüche
• Digitale Signaturen und Verschlüsselung zu Zusicherungen für durchgängige Sicherheit
• Föderierte Identität über Organisations- und Domänengrenzen hinweg
• Unterstützung für attributbasierte Autorisierung - beinhaltet Rollen und Berechtigungen zusammen mit Identitätsansprüchen
• Browserbasierter SSO-Ablauf Verwendung von HTTP-Weiterleitungen und POST-Bindungen

Wo SAML verwendet wird

SAML-basiertes SSO ist die Standardwahl in Unternehmensumgebungen, die hohe Sicherheit und domänenübergreifende Föderation erfordern. Typische Anwendungsfälle sind:

• Anbindung von Unternehmensanwendungen (Salesforce, Workday, ServiceNow) an einen Identitätsanbieter wie Active Directory, Okta oder miniOrange
• Regierungs- und Gesundheitsportale, die einen föderierten Zugriff mit strengen Prüfprotokollen erfordern
• B2B-SaaS-Plattformen, die die bestehende Identitätsinfrastruktur von Unternehmenskunden unterstützen müssen
• Compliance-orientierte Umgebungen, in denen HIPAA, SOC 2 oder ISO 27001 starke Authentifizierungskontrollen vorschreiben.

Was ist SSO?

Single Sign-On (SSO)-Software ist eine Authentifizierungsmethode, die es Benutzern ermöglicht, mit einem einzigen Satz von Anmeldeinformationen auf mehrere Anwendungen zuzugreifen – sie melden sich einmal an, und die Sitzung wird auf allen verbundenen Systemen fortgesetzt, ohne dass sie erneut nach Anmeldeinformationen gefragt werden.

SSO ist ein Nutzungsmuster, kein Protokoll. Es kann mithilfe verschiedener Basistechnologien implementiert werden, darunter SAML, OAuth 2.0, OpenID Connect (OIDC) oder LDAP. Gemeinsames Ergebnis ist der reibungslose Zugriff auf alle Systeme.

Hauptmerkmale von SSO

• Ein Login, viele Anwendungen - Vermeidet die wiederholte Eingabe von Anmeldeinformationen
• Zentralisierte Sitzungsverwaltung - Einmal abmelden und die Sitzung wird überall beendet.
• Reduzierte Passwortmüdigkeit Weniger Zugangsdaten bedeuten weniger schwache oder wiederverwendete Passwörter.
• Schnelleres Onboarding und Offboarding - Die Bereitstellung und der Entzug von Zugriffsrechten erfolgen an einem einzigen Punkt
• Protokollflexibilität Organisationen können je nach ihrer Technologieinfrastruktur SAML, OIDC oder andere Standards auswählen.

Wo SSO verwendet wird

SSO und SAML treten im Unternehmenskontext häufig gemeinsam auf, SSO findet jedoch sowohl in Verbraucher- als auch in Unternehmensumgebungen breite Anwendung:

• Mitarbeiterportale, die HR-Systeme, Projekttools und Kommunikationsplattformen miteinander verbinden.
• Verbraucher-Apps mit Social Login (Google, Facebook) – eine Form von SSO über OAuth und OIDC
• SaaS-Plattformen, die eine nahtlose Navigation zwischen Modulen ohne erneute Authentifizierung ermöglichen
• Jede Organisation, die die Belastung des Helpdesks durch Anfragen zum Zurücksetzen von Passwörtern reduzieren möchte.

SAML vs. SSO: Ein direkter Vergleich

Kurz gesagt: Die Frage „Ist SAML dasselbe wie SSO?“ ist so, als würde man fragen, ob eine Autobahn dasselbe ist wie eine Reise. Das eine ist die Infrastruktur, das andere das Ergebnis.

Funktionsweise von SAML SSO

Um zu verstehen, wie SAML SSO funktioniert, muss man einem strukturierten Austausch zwischen drei Parteien folgen: dem Benutzer, dem Identitätsanbieter und dem Dienstanbieter.

Hier ist der Standard-SAML-SSO-Ablauf Schritt für Schritt:

1. Benutzer fordert Zugriff an – Der Benutzer versucht, auf einen Dienstanbieter (z. B. Salesforce) zuzugreifen, ohne über eine aktive Sitzung zu verfügen.

2. SP generiert eine SAML-Anfrage - Der SP erstellt eine Authentifizierungsanfrage und leitet den Browser des Benutzers zum IdP weiter.

3. Der IdP authentifiziert den Benutzer - Falls der Benutzer noch nicht authentifiziert ist, fordert der IdP Anmeldeinformationen (Passwort, MFA usw.) an.

4. Der IdP stellt eine SAML-Assertion aus – Nach erfolgreicher Authentifizierung generiert der IdP eine digital signierte XML-Assertion, die die Identität und Attribute des Benutzers enthält.

5. Die Assertion wird an den SP gesendet - Der Browser übermittelt die SAML-Antwort (via HTTP POST oder Redirect) zurück an den Dienstanbieter.

6. SP validiert und gewährt Zugriff - Der SP verifiziert die Signatur, prüft die Assertion und gewährt dem Benutzer Zugriff auf die Anwendung.

Dieser gesamte SAML-SSO-Authentifizierungsvorgang läuft innerhalb von Sekunden ab und ist für den Endbenutzer unsichtbar. Der Benutzer sieht lediglich eine Anmeldeaufforderung – alles Weitere wird im Hintergrund abgewickelt.

Es ist außerdem erwähnenswert, dass SAML SSO in zwei Modi funktionieren kann:

• SP-initiierter FlussDer Benutzer beginnt beim Dienstanbieter und wird zum Identitätsanbieter weitergeleitet.
• IdP-initiierter FlussDer Benutzer beginnt auf dem IdP-Dashboard und klickt sich zum SP durch.

SAML-Architektur und Kernkomponenten

Um die SAML-Architektur zu verstehen , müssen Sie die vier Bausteine ​​kennen, die das Funktionieren des Systems ermöglichen.

Identitätsanbieter (IdP)

Der Identitätsanbieter (IdP) ist die maßgebliche Quelle für die Benutzeridentität. Er speichert Anmeldeinformationen, führt die Authentifizierung durch und stellt SAML-Assertions aus. Gängige IdPs sind beispielsweise Active Directory Federation Services (ADFS), Okta, Microsoft Entra ID, Keycloak und miniOrange. Der IdP ist der Vertrauensanker – Dienstanbieter verlassen sich darauf, dass er die Identität des Benutzers bestätigt.

Dienstleister (SP)

Der Dienstanbieter ist die Anwendung, auf die der Benutzer zugreifen möchte – beispielsweise Salesforce, Workday, GitHub oder ein anderes SAML-fähiges Tool. Der Dienstanbieter authentifiziert Benutzer nicht direkt. Stattdessen delegiert er diese Aufgabe an den Identitätsanbieter und akzeptiert Zusicherungen als Identitätsnachweis.

SAML-Behauptung

Eine SAML-Assertion ist ein XML-Dokument, das vom Identitätsanbieter (IdP) ausgestellt und vom Dienstanbieter (SP) verarbeitet wird. Sie enthält drei Arten von Anweisungen:

• Authentifizierungsanweisungen - bestätigen, dass der Benutzer zu einem bestimmten Zeitpunkt mit einer bestimmten Methode authentifiziert wurde
• Attributaussagen - enthalten Benutzerattribute wie E-Mail-Adresse, Rolle oder Abteilung, die der Service Provider für Autorisierungsentscheidungen verwenden kann.
• Genehmigungsentscheidungen - angeben, ob der Benutzer auf eine bestimmte Ressource zugreifen darf

Die Aussagen werden digital mit X.509-Zertifikaten signiert und können zur zusätzlichen Vertraulichkeit verschlüsselt werden.

Authentifizierungsablauf

Der SAML-SSO-Ablauf basiert auf einer während der Konfiguration hergestellten Vertrauensbeziehung: Der Service Provider (SP) ist mit den Metadaten des Identity Providers (IdP) (Signaturzertifikat, Endpunkt-URLs) vorkonfiguriert, und der IdP ist mit den Details des SP konfiguriert. Diese gegenseitige Einrichtung gewährleistet, dass Zusicherungen nur von bekannten, verifizierten Quellen als vertrauenswürdig eingestuft werden – ein wesentlicher Grund dafür, dass SAML-basiertes SSO in Unternehmensumgebungen ein so hohes Sicherheitsniveau aufweist.

Warum werden SAML und SSO oft verwechselt?

Es gibt einige Gründe, warum die Unterschiede zwischen SSO und SAML im alltäglichen Gebrauch verschwimmen:

Sie arbeiten eng zusammen. In der Unternehmens-IT basieren die meisten SSO-Implementierungen im Hintergrund auf SAML. Wenn Administratoren sagen: „Wir haben SSO eingerichtet“, meinen sie oft: „Wir haben SAML-SSO konfiguriert“ – der Begriff SSO wird in vielen Unternehmensgesprächen implizit als Synonym für SAML verwendet.

Der Begriff „SAML SSO“ ist allgegenwärtig. In Herstellerdokumentationen, Compliance-Checklisten und Produkteinstellungen wird „SAML SSO“ routinemäßig als zusammengesetzter Begriff verwendet. Diese enge Verknüpfung erweckt den Eindruck, die beiden Begriffe seien synonym, obwohl sie es nicht sind.

Andere Protokolle sind weniger präsent. SSO kann zwar auch mit OAuth 2.0, OpenID Connect oder LDAP funktionieren – da SAML jedoch der Standard in Unternehmen ist, werden die Alternativen seltener diskutiert. Dadurch wirkt SAML eher wie SSO selbst als wie ein Implementierungsweg.

SAML ist nicht die einzige Möglichkeit zur Implementierung von SSO

Es gibt verschiedene andere Protokolle, die SSO-Ergebnisse liefern können, jedes mit seinen eigenen Stärken:

SAML vs OpenID Connect (OIDC)

OpenID Connect (OIDC) ist eine moderne Identitätsschicht, die auf OAuth 2.0 aufbaut. Sie verwendet JSON Web Tokens (JWT) anstelle von XML, wodurch sie schlanker und besser für mobile Apps und moderne Webanwendungen geeignet ist. OIDC ist die bevorzugte Wahl für kundenorientiertes Single Sign-On (SSO) und von Entwicklern erstellte Anwendungen. SAML bleibt der Unternehmensstandard für föderierte B2B-Szenarien mit hohen Sicherheits- und Compliance-Anforderungen.

SAML vs. OAuth

OAuth 2.0 ist ein Autorisierungsframework, kein Authentifizierungsprotokoll – eine wichtige Unterscheidung. OAuth regelt die Berechtigungen von Benutzern und Anwendungen (Zugriffsbereiche, API-Berechtigungen), während SAML die Identität des Benutzers festlegt . Wenn von „OAuth für SSO“ die Rede ist, ist in der Regel OIDC zusätzlich zu OAuth gemeint. SAML wickelt sowohl den Identitäts- als auch den Attributaustausch in einer einzigen, streng kontrollierten Assertion ab.

SAML vs. LDAP

LDAP (Lightweight Directory Access Protocol) ist ein Verzeichnisabfrageprotokoll, das zum Auffinden von Benutzerinformationen in Verzeichnissen wie Active Directory verwendet wird. LDAP selbst unterstützt Single Sign-On (SSO) in Webanwendungen nicht nativ – hierfür sind zusätzliche Integrationsschichten erforderlich. SAML hingegen ist speziell für webbasiertes SSO mit integrierter Föderation und Verschlüsselung entwickelt. Viele Organisationen nutzen LDAP als Benutzerverzeichnis, während SAML die darüberliegende föderierte Authentifizierungsschicht übernimmt.

Vorteile und Grenzen von SAML

Vorteile

• Hohe SicherheitDie Aussagen werden signiert und optional verschlüsselt, um Manipulation oder Abfangen zu verhindern.
• Ausgereifter StandardSAML 2.0 ist seit über 15 Jahren im Produktiveinsatz und wird von vielen Herstellern unterstützt.
• VerbundzugriffFunktioniert organisations- und domänenübergreifend ohne Weitergabe von Anmeldeinformationen.
• Feingranularer AttributaustauschUnterstützt Rollen-, Abteilungs- und Berechtigungsdaten neben der Identität
• Compliance-bereitWird in den Rahmenwerken von HIPAA, SOC 2, ISO 27001 und NIST häufig als anerkannter Authentifizierungsmechanismus referenziert.

Einschränkungen

• Komplexität der ImplementierungDie SAML-Konfiguration erfordert die Verarbeitung von XML-Daten, die Verwaltung von Zertifikaten und einen präzisen Metadatenaustausch zwischen Identitätsanbieter (IdP) und Service Provider (SP).
• XML-OverheadAusführliche XML-Nutzdaten sind umfangreicher als JSON-basierte Alternativen wie JWT.
• BrowserabhängigkeitDer Standard-SAML-Ablauf setzt einen browserbasierten Umleitungsmechanismus voraus – er ist daher weniger geeignet für native mobile Apps oder die API-zu-API-Authentifizierung.
• Debugging-SchwierigkeitWenn SAML fehlschlägt, kann die Diagnose von Assertionsfehlern ohne spezialisierte Werkzeuge zeitaufwändig sein.
• ErsteinrichtungszeitDie Konfiguration einer neuen SAML-Integration erfordert eine Abstimmung zwischen dem IdP-Administrator und dem IT-Team des SP.

Häufige Anwendungsfälle für SAML SSO

SAML-basiertes Single Sign-On ist die bevorzugte Wahl in bestimmten Szenarien, in denen Sicherheit, Compliance und domänenübergreifende Föderation unabdingbar sind:

• Zugriff auf Enterprise-SaaS: Mitarbeiter über einen zentralen Identitätsanbieter mit Cloud-Anwendungen (Salesforce, Jira, Zoom) verbinden, ohne separate Anmeldeinformationen für jede Anwendung verwalten zu müssen.
• Identitätsföderation im GesundheitswesenKrankenhäuser und Kliniken nutzen föderiertes SAML-SSO, um einen sicheren Zugriff auf alle Behandlungssysteme zu ermöglichen und gleichzeitig die HIPAA-Konformität zu gewährleisten.
• Regierungs- und BildungsportaleBehörden- oder institutionsübergreifender Zugriff, bei dem jede Organisation ihren eigenen Identitätsanbieter unterhält, die Nutzer aber nahtlosen Zugriff auf gemeinsam genutzte Ressourcen benötigen.
• B2B-SaaS-Plattformen: Produktteams, die Unternehmenskunden integrieren müssen, die bereits über eigene SAML-konforme Identitätsanbieter (Okta, Entra ID, ADFS) verfügen.
• Zugang für Auftragnehmer und Partner: Gewährung von temporärem, attributbasiertem Zugriff für externe Benutzer ohne Bereitstellung von Konten im eigenen Verzeichnis der Organisation.

Wann sollte man SAML und wann andere SSO-Protokolle verwenden?

Die Wahl zwischen SAML und anderen SSO-Implementierungen hängt von Ihrer Zielgruppe, Ihrem Anwendungsfall und Ihrer technischen Umgebung ab.

SAML SSO verwenden, wenn:

• Unternehmenskunden benötigen eine föderierte Identität mit ihrem eigenen Identitätsanbieter.
• Sie integrieren Active Directory, Okta, Microsoft Enterprise ID (Azure AD) oder ähnliche Identitätsanbieter für Unternehmen.
• Es gelten hohe Sicherheits- und Compliance-Standards – HIPAA, SOC 2, ISO 27001, PCI-DSS
• Sie entwickeln ein B2B-SaaS-Produkt und müssen das Onboarding von Unternehmenskunden unterstützen.
• Eine domänenübergreifende Föderation über Organisationen oder Abteilungen hinweg ist erforderlich.

Verwenden Sie SSO mit anderen Protokollen (OIDC, OAuth), wenn:

• Ihre Nutzer sind Privatkunden oder KMU-Kunden, die keine unternehmensweite IdP-Infrastruktur besitzen.
• Priorität hat ein unkompliziertes, reibungsloses Anmeldeerlebnis gegenüber komplexen Föderationen.
• Sie entwickeln interne Mitarbeiterportale mit einer modernen, API-zentrierten Architektur.
• Mobile-First- oder native App-basierte SSO-Lösungen sind das Ziel – OIDC eignet sich hierfür besser als SAML.
• Entwicklungsgeschwindigkeit und Integrationsfreundlichkeit haben Vorrang vor den Compliance-Anforderungen des Unternehmens.

Viele etablierte Unternehmen nutzen beides: SAML für die Unternehmenskundenföderation, OIDC oder OAuth für interne Entwicklertools und kundenorientierte Produkte.

Häufig gestellte Fragen

Sind SAML und SSO dasselbe?

Nein. SSO ist ein Authentifizierungskonzept – die Möglichkeit, sich einmal anzumelden und auf mehrere Anwendungen zuzugreifen. SAML ist ein Protokoll – einer der technischen Standards zur Implementierung von SSO. SAML ist eine Möglichkeit, SSO zu realisieren; SSO kann aber auch mit OpenID Connect, OAuth 2.0 oder LDAP umgesetzt werden. Die beiden Begriffe sind eng verwandt, aber nicht austauschbar.

Ist SSO ohne SAML möglich?

Ja. SSO erfordert kein SAML. OpenID Connect (OIDC) ist eine weit verbreitete Alternative für moderne Web- und Mobilanwendungen. OAuth 2.0 mit OIDC ist besonders bei Endkunden-Apps und Entwicklerplattformen üblich. LDAP-basiertes SSO existiert auch in internen Netzwerkumgebungen. SAML ist die bevorzugte Wahl für Unternehmens- und B2B-Szenarien, aber nicht der einzige Weg zu SSO.

Was ist SAML 2.0 SSO?

SAML 2.0 ist die aktuelle Version des SAML-Standards, veröffentlicht im Jahr 2005 und weiterhin im Einsatz. SAML 2.0 SSO bezeichnet die Implementierung von Single Sign-On (SSO) mithilfe des SAML 2.0-Protokolls. Es bietet Verbesserungen gegenüber SAML 1.1, darunter die Unterstützung mehrerer Anwendungsfälle für Verbundnetzwerke, bessere Verschlüsselungsoptionen und eine umfassendere Interoperabilität zwischen Identitätsanbietern (IdP) und Dienstanbietern (SP). Nahezu alle SAML-Implementierungen in Unternehmen nutzen heute SAML 2.0.

Warum bevorzugen Unternehmen SAML SSO?

Unternehmen bevorzugen SAML-SSO aus mehreren Gründen. Es unterstützt föderierte Identitäten über Organisationsgrenzen hinweg, sodass Mitarbeiter mit ihren Unternehmensanmeldeinformationen auf Partner- oder Lieferantensysteme zugreifen können. SAML-Assertions enthalten umfangreiche Benutzerattribute (Rollen, Abteilungen, Berechtigungsstufen), die eine differenzierte Autorisierung ermöglichen. Zudem wird SAML von vielen Anbietern von Unternehmenssoftware unterstützt und ist mit Compliance-Rahmenwerken wie HIPAA, SOC 2 und ISO 27001 kompatibel.

Wie funktioniert SAML SSO?

Wenn ein Benutzer versucht, auf eine Anwendung (den Dienstanbieter) zuzugreifen, leitet dieser ihn mit einer SAML-Authentifizierungsanfrage an den Identitätsanbieter weiter. Der Identitätsanbieter überprüft die Identität des Benutzers – per Passwort, Multi-Faktor-Authentifizierung (MFA) oder einer bestehenden Sitzung – und generiert anschließend ein signiertes XML-Dokument, die sogenannte SAML-Assertion. Diese Assertion wird über den Browser des Benutzers an den Dienstanbieter zurückgesendet. Der Dienstanbieter validiert die Signatur mithilfe des Zertifikats des Identitätsanbieters, liest die Identität und Attribute des Benutzers aus der Assertion und gewährt den Zugriff.