SAML vs. OIDC: die Protokollfrage hinter jedem SSO-Projekt – verständlich erklärt

Die Frage kommt selten von Entwicklern: Sie steht im Sicherheitsfragebogen des Einkaufs, irgendwo zwischen ISO-Zertifikat und Auftragsverarbeitung. Sobald deine Software oder dein Portal an Konzernkunden geht, verlangt deren IT Single Sign-on über den eigenen Identity Provider (IdP), also den zentralen Anmeldedienst des Unternehmens. Und dieser Dienst spricht in vielen Konzernen ein Protokoll namens SAML.

Dahinter steckt die Protokollfrage jedes SSO-Projekts: SAML oder OIDC? Beide Standards lösen dasselbe Problem – eine Anwendung delegiert das Login an einen vertrauenswürdigen Identitätsdienst, statt selbst Passwörter zu verwalten. Sie stammen nur aus verschiedenen Epochen der Web-Geschichte, und genau aus diesem Altersunterschied entstehen die meisten Missverständnisse.

Warum das für dich als Entscheider zählt: Im Vendor-Review reicht ein unbeantwortetes „Unterstützt ihr SAML?“, um einen fünfstelligen Jahresvertrag wochenlang aufzuhalten. Dieser Artikel erklärt beide Protokolle ohne eine Zeile Code: was sie sind, worin sie sich unterscheiden und wie du entscheidest, ohne einen Deal zu gefährden.

Vorab die Definition: SAML steht für Security Assertion Markup Language und ist ein XML-basierter Standard, mit dem ein Identity Provider einer Anwendung bestätigt, wer sich gerade angemeldet hat. Die heute genutzte Version 2.0 ist ein OASIS-Standard vom 15. März 2005 – und seither im Kern unverändert im Einsatz.

Das Alltagsbild: Eine SAML-Bestätigung (Assertion) ist eine beglaubigte Urkunde. Deine Anwendung schickt den Nutzer zum „Amt“, dem Identitätsdienst seines Arbeitgebers. Dort weist er sich aus, und zurück kommt ein digital signiertes Dokument: Diese Person ist Frau Meier aus dem Einkauf, geprüft und gesiegelt. Förmlich und wortreich – aber im gesamten Unternehmensverkehr anerkannt.

Das Format passt zur Epoche: Anfang der 2000er war XML die Verkehrssprache der Unternehmens-IT, entsprechend ausführlich fallen SAML-Nachrichten aus. Für Menschen sind sie mühsam zu lesen, für die Systeme jener Zeit waren sie ideal. Die Sperrigkeit ist kein Mangel, sondern ein Zeitstempel.

Die Herkunft erklärt den Charakter: SAML entstand für die Federation, den Vertrauensbund zwischen Organisationen. Der klassische Fall: Mitarbeiter eines Konzerns melden sich bei der Software eines Dienstleisters mit ihrem Firmenkonto an, ohne dort je ein Passwort zu besitzen. Ausscheidende Mitarbeiter verlieren automatisch alle Zugänge – für die Konzern-IT ist das der eigentliche Wert.

Zwei Rollen solltest du kennen, weil sie in jedem Anbindungsgespräch fallen: Der Identity Provider (IdP) bestätigt Identitäten, der Service Provider (SP) ist die Anwendung, die dieser Bestätigung vertraut – im Enterprise-Deal bist du der Service Provider. Das Vertrauen zwischen beiden wird einmalig eingerichtet, über den Austausch von Metadaten und Zertifikaten.

Der Merksatz: SAML ist für Browser und Bürowelt gebaut – Webanwendungen im Unternehmensumfeld, nicht Apps auf dem Smartphone.

Auch hier zuerst die Definition: OIDC steht für OpenID Connect und ist eine Identitätsschicht auf OAuth 2.0, einem Framework für delegierte Zugriffe. Die OpenID Foundation hat den Standard am 25. Februar 2014 finalisiert. Statt XML-Dokumenten nutzt OIDC kompakte JSON-Datenpakete; das Herzstück ist das ID-Token im JWT-Format (JSON Web Token).

Das Alltagsbild dazu: Ein ID-Token ist ein digitaler Boarding-Pass. Klein, maschinenlesbar, kryptografisch gegen Fälschung gesichert – und er funktioniert überall: im Browser, in der nativen App, an der Programmierschnittstelle. Deine Anwendung liest den Pass und weiß in Millisekunden, wer vor ihr steht und wie lange die Anmeldung gilt.

Die Herkunft ist die Gegenwelt zu SAML: OIDC wurde von Google, Microsoft und anderen Web-Konzernen für die Zeit nach dem Smartphone-Durchbruch entworfen. Single-Page-Anwendungen, native Apps, APIs, Microservices: überall dort ist OIDC heute der Standardweg. Jedes „Login mit Google“ auf einer Website ist technisch OIDC.

Dazu kommt das Ökosystem: Moderne Verfahren wie Passkeys und Mehrfaktor-Authentifizierung docken zuerst an OIDC-Infrastruktur an, und praktisch jede aktuelle Bibliothek bringt die Unterstützung fertig mit. Für dich heißt das: kürzere Projektlaufzeiten und weniger Spezialwissen im Team, wenn OIDC der Weg ist.

Der Kern in einem Satz: OIDC liefert dieselbe beglaubigte Bestätigung wie SAML – nur im Format der modernen Web- und App-Entwicklung.

Zur Orientierung die wichtigsten Unterschiede nebeneinander. Die Tabelle ersetzt keine Architekturentscheidung, aber sie zeigt das Muster hinter allen Details: SAML ist der etablierte Standard der Unternehmens-IT, OIDC der Standard für alles Neue.

Ein Lesehinweis zur letzten Zeile: „Höher“ heißt nicht unbeherrschbar. SAML-Anbindungen sind Routine, wenn das Werkzeug stimmt – mit einem eingespielten Setup rechnen wir pro Enterprise-IdP mit ein bis drei Tagen Aufwand. Es heißt aber: mehr Konfigurationsdetails, mehr Abstimmung mit der Gegenseite, mehr Geduld bei der Fehlersuche.

Die gute Nachricht vorweg: Du musst dich seltener entscheiden, als die Überschrift vermuten lässt. Die eigentliche Frage lautet nicht „welches Protokoll ist besser“, sondern „wer gibt das Protokoll vor“. Drei Konstellationen decken fast alle Projekte ab.

Dein Kunde bringt einen Enterprise-IdP mit: Dann gibt dessen System den Takt vor. ADFS, ältere Entra-ID-Konfigurationen und viele SAP- und HR-Landschaften sprechen SAML – und keine Konzern-IT ändert ihre Identitätsinfrastruktur für einen einzelnen Lieferanten. Wer hier nur OIDC anbietet, verliert den Deal oder verhandelt wochenlang über Sonderlösungen.

Du baust neue Anwendungen: Dann ist OIDC gesetzt. Jede aktuelle Web- und App-Technologie bringt die Unterstützung mit, die Token passen zu APIs und Microservices, Passkeys und MFA fügen sich ein. Ein neues System exklusiv auf SAML zu bauen, wäre 2026 eine Entscheidung gegen den Strom.

Du brauchst beides: der Normalfall im B2B. Deine Anwendungen sprechen intern OIDC, deine Enterprise-Kunden liefern Identitäten per SAML an. Genau dafür gibt es Identity-Broker: Keycloak spricht beide Protokolle gleichzeitig und übersetzt dazwischen – deine Anwendung bekommt davon nichts mit. Neue Kunden-IdPs bindest du per Konfiguration an, nicht per Programmierung.

Für die Planung heißt das: Die Protokollfähigkeit gehört in die Architektur, bevor der erste Enterprise-Kunde sie verlangt. Der Broker kostet am Anfang wenige Projekttage; ihn nachträglich unter ein laufendes System zu schieben, kostet ein Vielfaches – samt Migration aller Bestandskonten.

Wie so eine Brücke praktisch aussieht, zeigt unser Beitrag zur SSO- und ERP-Anbindung im Kundenportal. Und falls Keycloak bei dir nicht gesetzt ist: Auch die meisten Keycloak-Alternativen beherrschen beide Protokolle. Die Protokollfrage ist von der Produktfrage getrennt zu beantworten – erst der Bedarf, dann das Werkzeug.

Verdichtet auf zwei Sätze: SAML sprichst du, weil deine Kunden es sprechen. OIDC sprichst du, weil deine Anwendungen es sprechen – und ein Broker sorgt dafür, dass beides gleichzeitig gilt.

Zum Schluss die vier Sätze, die in Protokolldiskussionen die meiste Verwirrung stiften – und was stattdessen stimmt.

„SAML ist veraltet“: Halb richtig, ganz irreführend. Der Standard ist von 2005 und wird nicht mehr weiterentwickelt – aber er ist deshalb nicht nutzlos, sondern fertig. Millionen Unternehmens-Logins laufen täglich darüber, und kein Konzern löst seine Federation kurzfristig ab. Veraltet wäre allein, ein neues System exklusiv auf SAML zu bauen.

„OAuth2 ist ein Login-Protokoll“: Nein. OAuth 2.0 (RFC 6749, IETF, Oktober 2012) regelt Autorisierung, also delegierten Zugriff auf Ressourcen. Wer der Nutzer ist, klärt die Spezifikation nicht – die Authentifizierung erklärt sie ausdrücklich für außerhalb ihres Geltungsbereichs. Das Alltagsbild: OAuth2 ist die Hotel-Schlüsselkarte. Sie öffnet Türen, aber sie ist kein Ausweis. Erst OIDC ergänzt den Ausweis.

„OIDC ist unsicherer, weil einfacher“: Das Gegenteil trifft eher zu. Einfachere Standards werden häufiger korrekt umgesetzt, und die Fehlerklassen von XML-Signaturen (Stichwort Signature Wrapping) haben SAML-Implementierungen jahrelang begleitet. Sicherheit entsteht in beiden Welten durch saubere Umsetzung und gepflegte Bibliotheken, nicht durch das Protokolletikett.

„Wir müssen uns festlegen“: Musst du nicht. Die Protokollfrage entscheidet sich pro Anbindung, nicht pro Unternehmen. Ein zentraler Identitätsdienst bedient die SAML-Anforderung des Konzernkunden und das OIDC-Login deiner eigenen App aus derselben Nutzerverwaltung – ohne doppelte Konten, ohne doppelte Pflege.

Liegt gerade ein Sicherheitsfragebogen mit der SAML-Frage auf deinem Tisch? Dann ist die Antwort selten ein Umbau, sondern meist eine überschaubare Architekturentscheidung. Wir bauen Kundenportale mit genau dieser Brückenarchitektur: OIDC für die Anwendung, SAML für die Enterprise-Anbindung – abgestimmt auf die Identity Provider, die deine Kunden real mitbringen.

Im kostenlosen Erstgespräch klären wir in 30 Minuten deinen konkreten Fall: welche Identity Provider deine Kunden nutzen, ob ein Broker nötig ist und was die Anbindung kosten wird. Du bekommst eine ehrliche Einschätzung – auch dann, wenn die Antwort lautet: Dafür brauchst du uns nicht.