SAML vs. OIDC: Was ist der beste Ansatz für Ihr Unternehmen?

Was sind SAML (Security Assertion Markup Language) und OIDC (OpenID Connect)? Beide sind Authentifizierungsprotokolle, die einen Single Sign-On (SSO) ermöglichen. Welches eignet sich besser für Ihr Unternehmen? Wir stellen Ihnen beide Protokolle vor, wie sie arbeiten, was sie auszeichnet und welches für Ihr Unternehmen am besten geeignet ist.

Single Sign-On (SSO)

Was ist ein Single Sign-On und warum ist er wichtig? Jeder Benutzer verwendet tagtäglich viele Apps, Programme und Software. Werden für all diese verschiedenen Dinge Benutzernamen und Passwörter benötigt, gerät die Sache schnell außer Kontrolle. Ein Single Sign-On (SSO) erleichtert Nutzern das Leben erheblich, denn sie müssen sich nur noch an einer Stelle authentifizieren. Benutzernamen- und Passwortdatenbanken werden überflüssig. Mit nur einer ID erhalten Benutzer sicheren Zugriff auf viele Anwendungen und Dienste.

Ein SSO verwendet ein Authentifizierungsprotokoll, das bedeutet vertrauenswürdige, aber unabhängige Systeme tauschen Informationen zu Identitäten aus.

Das Standardprotokoll definiert, wie dieser Austausch stattfindet. SAML und OIDC sind zwei gängige Protokolle für ein erfolgreiches Identity Management. SAML ist die Abkürzung für Security Assertion Markup Language und wird häufig in Arbeitsumgebungen eingesetzt. OIDC kommt beispielsweise zum Einsatz, wenn sich ein Nutzer mit seinem Google-Konto bei einer Anwendung wie YouTube anmeldet.

Was ist SAML?

Dieses Standardprotokoll organisiert die reibungslose Zusammenarbeit der Hauptakteure bei der Authentifizierung. Der Kunde authentifiziert sich an einem Ort, alle Anwendungen werden entsprechend informiert. Die drei Hauptakteure beim Identity Management sind der Benutzer, der Service Provider und der sogenannte Identity Provider. Service Provider sind verschiedene Anwendungen, auf die ein Kunde zugreifen möchte wie Office 365, Webex, Concur und Salesforce. Plant der Kunde beispielsweise Webex zu nutzen, dann fordert Webex, der Service Provider, eine SAML-Authentifizierung an. Der Browser leitet den Kunden mit dieser Anforderung an den Identity Provider weiter. Hier wird sich der Kunde authentifizieren. Dies kann durch Benutzername und Kennwort erfolgen, durch eine Zwei-Faktor-Authentifizierung oder beliebige andere Authentifizierungsmittel oder -mechanismen.

Die Assertion

Sobald der Identity Provider den Kunden als rechtmäßig authentifiziert hat, erstellt er eine sogenannte Assertion. Die Assertion ist ein XML-Dokument. XML ist eine sogenannte Auszeichnungssprache, um Daten strukturiert zu speichern. Die Assertion enthält Informationen über den Kunden und seine Zugriffsrechte. Um die Echtheit der enthaltenen Daten sicherzustellen, ist sie kryptografisch signiert. Diese SAML-Assertion leitet der Browser an den Service Provider weiter – in unserem Beispiel Webex. Dieser überprüft mittels sogenannter Public-Key-Kryptografie die Signatur und der Kunde erhält Zugriff.

Vorteile von Security Assertion Markup Language

Das Protokoll bildet eine externe Struktur innerhalb der Service Provider und Identity Provider Daten zur Authentifizierung und Autorisierung austauschen können. Verschiedene Akteure können den Identitäten des jeweils anderen vertrauen, ohne sensible Informationen preiszugeben. Es ist ein sehr verlässliches und stabiles Protokoll, um die IT-Sicherheit zu garantieren. Insbesondere eignet es sich für Bereiche, in denen viele Identitätsgruppen – Gruppen von Benutzern mit unterschiedlichen Rechten – agieren. SAML glänzt in Enterprise-Szenarien, die detaillierte Audit-Trails, komplexes Attribut-Mapping und die Integration mit Legacy-Systemen in Sektoren wie Gesundheitswesen, Behörden und Finanzdienstleistungen erfordern.

Was ist OIDC?

OpenID Connect kurz OIDC ist ebenfalls ein Standardprotokoll und legt Regeln fest, wenn Unternehmen die Authentifizierung auslagern. Der Ablauf ist folgendermaßen: Der Anwender will auf einen Service Provider zugreifen. Dieser kennt den Anwender nicht und sendet deshalb eine Anfrage an den Identity Provider. Das ist der vertrauenswürdige Dritte, der Nutzer authentifiziert und entsprechende Dokumente ausstellt.

Der Identity Provider schickt ein Dokument mit Claims zurück. Was heißt das? Ein Claim ist eine Behauptung. In unserem Fall kann der Claim der Name des Mitarbeiters sein, seine Rolle im Unternehmen oder die Kontaktdaten. Der Service Provider muss diesem Dokument vertrauen, es muss wahrheitsgemäße Daten enthalten. Dazu wird das Ganze vom Identity Provider mit einem Private Key digital signiert. Der Service Provider prüft die Signatur mithilfe eines Public Keys oder dem Zertifikat des Identity Providers.

Das Token

Dieses Dokument mit Claims und Signatur ist ein sogenanntes Token. Auch dafür gibt es einen Standard, JWT - JSON Web Token - ein JSON-Objekt mit einer angehängten Signatur. Das ist die digitale Variante eines Personalausweises, den die Bundesdruckerei ausstellt und des Rathauses, das die Identität verifiziert. Das Rathaus fungiert als Identity Provider, will sich der Nutzer ausweisen, wird dem Ausweis vertraut.

Ein JSON Web Token enthält eine ID für den Nutzer in dem Feld Subject, abgekürzt „sub". Daneben gibt es eine Reihe anderer Felder wie „issued at" (abgekürzt „iat") oder „expires at" (abgekürzt „exp"). Je nach Identity Provider lassen sich im Token weitere Felder hinterlegen, zu viele Felder darf er nicht haben. Der Token wird bei jedem Request mitgeschickt und würde den Datenverkehr zu sehr belasten. All diese Abläufe und Standards entsprechen dem Authentifizierungsprotokoll von OpenID Connect.

Vorteile von OpenID Connect

Token eignen sich gut für hochskalierbare Web- und Cloudanwendungen. Ein Nachteil ist, dass immer eine Umleitung (Redirect) erforderlich ist. OpenID Connect funktioniert gut im Webbrowser, jedoch nicht in einer mobilen oder in einer Desktop-App. Das gilt jedoch nur für den „Implicit Flow" von OpenID Connect. Er ist speziell für Single-Page-Anwendungen, also dediziert für den Browser gestaltet. Daneben gibt es andere Flows, beispielsweise den Code Flow oder den Hybrid Flow. Sie funktionieren gut für mobile Apps oder generell für Anwendungen, die keine Single-Page-Applications sind oder nicht im Browser laufen.

Implementierung des OIDC Client Credentials Flow

Für Machine-to-Machine-Authentifizierungsszenarien bietet der Client Credentials Flow von OIDC einen optimierten Ansatz für Backend-Services:

1. Registrieren Sie Ihren vertraulichen Client bei Ihrem Identity Provider und aktivieren Sie den Client Credentials Grant Type
2. Fordern Sie ein Access Token an, indem Sie einen POST-Request an den Token-Endpoint senden:

curl -X POST https://your-idp.com/oauth2/token \
  -H "Authorization: Basic BASE64(client_id:client_secret)" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&scope=your_scope"

3. Verwenden Sie das zurückgegebene Access Token in API-Aufrufen über den Authorization-Header: Bearer <access_token>

Dieser Flow ist ideal für Server-zu-Server-Kommunikation, bei der keine Benutzerinteraktion erforderlich ist, wie z.B. Datensynchronisation zwischen Geschäftssystemen oder automatisierte Reporting-Services.

Hauptunterschiede zwischen SAML und OIDC

Im Rahmen des Protokolls von OpenID Connect verwenden Benutzer JWT oder JSON Web Token. Damit tauschen verschiedene Dienste Informationen über die Identität aus. Ein JWT ist ein signiertes JSON-Dokument. Bei SAML werden sogenannte Assertions eingesetzt, kryptografisch signierte XML-Dokumente, die Informationen über den Benutzer und seine Rechte enthalten. Das Gesamtkonzept der beiden Protokolle ist dasselbe. Die Abläufe – die Flows – ähneln sich, die Details bei der Implementierung unterscheiden sich.

Unterschiede in der Implementierung und Nutzung

OIDC ist sehr einfach und ohne neue Infrastruktur zu implementieren, doch es funktioniert nur für einfache Szenarien. Eine sehr differenzierte Steuerung, eine komplexe Berechtigungsvergabe sind nicht möglich. Das Token wird dann schnell viel zu groß und überlastet den Datenverkehr. Für ein einfaches Szenario, beispielsweise die Frage Administrator oder normaler Anwender, reicht OIDC völlig aus. Plattformen wie Google, Facebook oder GitHub verwenden OIDC. Eine mobile App würde von der Effizienz von OpenID profitieren.

Security Assertion Markup Language ist schwieriger zu implementieren, doch die XML-codierten Assertions erlauben es, viele detaillierte Informationen zu speichern und weiterzugeben. Für Regierungsbehörden oder öffentliche Institutionen, die viele Zugänge kontrollieren und zahlreiche Berechtigungen verwalten, ist es die richtige Lösung. Auch Kliniken oder Dienstleistern im Gesundheitswesen garantiert es Unternehmenssicherheit durch den kontrollierten Zugriff auf Anwendungsportale oder sensible Daten.

Performance- und Skalierbarkeitsaspekte

Bei der Wahl zwischen SAML und OIDC für Enterprise-Anwendungen spielen Performance-Eigenschaften eine entscheidende Rolle.

Token-Größe und Netzwerk-Overhead

Die JWT-Tokens von OIDC sind deutlich kompakter als die XML-Assertions von SAML. Ein typisches JWT umfasst 200-400 Bytes, während SAML-Assertions aufgrund der XML-Ausführlichkeit und digitaler Signaturen 1-5 KB groß sein können. Für Anwendungen mit hohem Datenverkehr, die Tausende von Authentifizierungsanfragen verarbeiten, führt dieser Größenunterschied zu messbaren Bandbreiteneinsparungen und schnelleren Übertragungszeiten.

Verarbeitungsgeschwindigkeit

JSON-Parsing (OIDC) ist in den meisten Programmiersprachen und Frameworks generell schneller als XML-Parsing (SAML). Moderne Webanwendungen profitieren von nativer JSON-Unterstützung in Browsern und APIs, während SAML spezialisierte XML-Verarbeitungsbibliotheken erfordert, die zusätzlichen Rechenaufwand verursachen.

Skalierbarkeitsimplikationen

Die zustandslose JWT-Validierung von OIDC ermöglicht horizontale Skalierung ohne Abhängigkeiten von Session-Speicher. Das Assertion-basierte Modell von SAML erfordert oft komplexere Caching-Strategien und kann in Hochverfügbarkeits-Deployments mit Tausenden gleichzeitiger Benutzer Engpässe verursachen.

Welches Protokoll ist das richtige für Ihr Unternehmen?

Führende Identity Provider und Plattformunterstützung

Die Wahl des richtigen Protokolls hängt auch von Ihrem Identity-Provider-Ökosystem und Ihren Integrationsanforderungen ab.

Enterprise Identity Provider

SAML-starke Anbieter: Microsoft Entra ID, Okta, Ping Identity und OneLogin zeichnen sich durch SAML-Federation mit umfangreichen Enterprise-Features wie Conditional Access, detaillierten Audit-Trails und komplexem Attribut-Mapping aus.

OIDC-native Anbieter: Auth0, Amazon Cognito und Google Workspace bieten optimierte OIDC-Implementierungen mit entwicklerfreundlichen APIs und modernen Authentifizierungsflows.

Open-Source- und Self-Hosted-Optionen

Für Organisationen, die volle Kontrolle über ihre Identitätsinfrastruktur benötigen, bietet Keycloak umfassende SAML- und OIDC-Unterstützung mit umfangreichen Anpassungsmöglichkeiten. FusionAuth bietet eine entwicklerorientierte Alternative mit starken API-Fähigkeiten.

Integrationsüberlegungen

Die meisten modernen Plattformen unterstützen beide Protokolle, aber die Implementierungskomplexität variiert. Okta und Auth0 bieten einheitliche Dashboards zur Verwaltung von SAML- und OIDC-Verbindungen, während AWS Cognito sich nahtlos über OIDC-Flows in andere AWS-Services integriert.

Häufig gestellte Fragen

Kann ich SAML und OIDC gleichzeitig verwenden? Ja, die meisten Organisationen implementieren einen hybriden Ansatz und verwenden SAML für Legacy-Enterprise-Anwendungen und OIDC für moderne Web- und Mobile-Anwendungen. Identity Provider wie Unidy unterstützen beide Protokolle und ermöglichen eine nahtlose Integration über Ihren gesamten Anwendungsstack.

Welches Protokoll ist sicherer? Beide Protokolle sind bei korrekter Implementierung sicher. SAML bietet detaillierte Audit-Trails und Assertion-basierte Kontrollen, die in compliance-intensiven Umgebungen bevorzugt werden. OIDC bietet moderne kryptografische Standards und ist aufgrund seiner einfacheren JSON-Struktur weniger anfällig für Implementierungsfehler.

Wie migriere ich von SAML zu OIDC? Die Migration umfasst typischerweise den parallelen Betrieb beider Protokolle, wobei Anwendungen schrittweise auf OIDC umgestellt werden, während SAML für Legacy-Systeme beibehalten wird. Eine zentrale Identity-Plattform kann diesen Übergang ermöglichen, ohne bestehende Benutzererfahrungen zu beeinträchtigen.

Wie steht es um die Integrationskomplexität? OIDC erfordert generell weniger initiale Einrichtung und bietet eine bessere Entwicklererfahrung mit weit verbreiteter SDK-Unterstützung. SAML-Implementierungen erfordern oft mehr XML-Konfiguration und Zertifikatsmanagement, bieten aber eine granularere Kontrolle über Benutzerattribute und Autorisierungsrichtlinien.

Fazit

Sowohl Security Assertion Markup Language als auch OpenID Connect sind Protokolle für ein erfolgreiches Identity Management. Ihr Einsatz ist keine Frage von Entweder-oder. Je nach Anwendungsfall lassen sich beide, auch in Kombination mit anderen Authentifizierungsstandards, einsetzen.

Für Enterprise-Anwendungen sollten Sie SAML in Betracht ziehen, wenn Sie detaillierte Kontrolle über Benutzerattribute, komplexe Berechtigungsstrukturen oder die Integration mit Legacy-Systemen benötigen. Wählen Sie OIDC für moderne Webanwendungen, mobile Plattformen und API-getriebene Architekturen, bei denen Entwicklererfahrung und Performance Priorität haben.

Der optimale Ansatz für die meisten Organisationen ist eine hybride Strategie: SAML für etablierte Enterprise-Workflows beibehalten und gleichzeitig OIDC für neue digitale Initiativen implementieren. Dies gewährleistet Kompatibilität über Ihr gesamtes Anwendungsportfolio und positioniert Ihre Infrastruktur für zukünftiges Wachstum.

Bei Unidy unterstützt unsere Identity-Management-Plattform sowohl SAML- als auch OpenID-Connect-Standards und ermöglicht nahtlose Integration unabhängig von Ihrem aktuellen Technologie-Stack. Ob Sie fragmentierte Logins konsolidieren oder eine umfassende Single-Sign-On-Strategie aufbauen – wir bieten die Flexibilität, Ihr digitales Ökosystem zu erweitern, ohne Sicherheit oder Benutzererfahrung zu kompromittieren.

Haben Sie weitere Fragen oder wünschen Sie eine detaillierte Beratung? Rufen Sie an oder schreiben Sie uns. Wir helfen Ihnen gerne weiter.

Zuletzt aktualisiert: Januar 2026 – Bleiben Sie auf dem Laufenden mit den neuesten Best Practices und Protokoll-Updates im Identity Management.