SAML vs. OIDC: das passende Protokoll für Single Sign-On

SAML vs. OIDC ist die Protokollentscheidung hinter Single Sign-On. Bei SAML 2.0 (OASIS-Standard, März 2005) signiert ein Identity Provider eine XML-Assertion über den Nutzer, die der Browser an den Service Provider weiterreicht. OpenID Connect (Core 1.0, Februar 2014, außerdem ISO/IEC 26131:2024) ergänzt OAuth 2.0 um eine Identitätsschicht: Der Provider stellt meist über den Autorisierungscode-Flow ein signiertes JWT aus, das ID-Token, und kann im selben Austausch auch Access Tokens für APIs ausstellen.

Auf einen Blick

Wie die Anmeldung jeweils abläuft

Bei SAML leitet der Service Provider den Browser mit einem AuthnRequest zum Identity Provider um. Nach der Anmeldung liefert der IdP ein HTML-Formular zurück, das eine base64-kodierte Response mit der Assertion absendet: Aussteller, Subject, Audience-Beschränkung, Gültigkeitszeitraum, Attribute und eine XML Signature. Der Service Provider prüft die Signatur mit dem Zertifikat aus den Metadaten des IdP und anschließend die Bedingungen.

Bei OpenID Connect leitet der Client zum Autorisierungsendpunkt des Providers um, mit scope=openid, einem state, einer nonce und einer PKCE-Challenge. Der Provider gibt einen Einmalcode an die Redirect-URI zurück; der Client tauscht ihn am Token-Endpunkt über eine direkte TLS-Verbindung gegen das ID-Token und das Access Token ein, sodass die Tokens nie die Adresszeile des Browsers passieren.

Das folgende Skript liest beide Arten von Konfiguration beim selben Provider aus (20. Oktober 2026, curl und jq 1.8.1). Bei wiederholten Abrufen schwankte die Größe der SAML-Metadaten zwischen 28 und 32 KB und das JWKS zwischen 7 und 8 Schlüsseln, weil jeweils andere Server antworteten.

#!/bin/sh
base=https://login.microsoftonline.com/common
echo "== OpenID Connect discovery"
curl -s "$base/v2.0/.well-known/openid-configuration" -o oidc.json
echo "bytes: $(wc -c < oidc.json | tr -d ' ')"
jq -c '{id_token_signing_alg_values_supported, response_types_supported}' oidc.json
curl -s "$(jq -r .jwks_uri oidc.json)" | jq -c '{jwks_keys: (.keys | length), kty: ([.keys[].kty] | unique)}'

echo "== SAML 2.0 metadata"
curl -s "$base/FederationMetadata/2007-06/FederationMetadata.xml" -o saml.xml
echo "bytes: $(wc -c < saml.xml | tr -d ' ')"
grep -o 'SignatureMethod Algorithm="[^"]*"' saml.xml | sort -u
grep -o 'SingleSignOnService Binding="[^"]*"' saml.xml | sort -u
echo "distinct certificates: $(grep -o '<X509Certificate>[^<]*' saml.xml | sort -u | wc -l | tr -d ' ')"
rm -f oidc.json saml.xml

== OpenID Connect discovery
bytes: 1728
{"id_token_signing_alg_values_supported":["RS256"],"response_types_supported":["code","id_token","code id_token","id_token token"]}
{"jwks_keys":7,"kty":["RSA"]}
== SAML 2.0 metadata
bytes: 28179
SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
distinct certificates: 5

Was eine Relying Party prüfen muss

SAML: Prüfe die XML Signature mit dem IdP-Zertifikat, das du konfiguriert hast (nie mit einem, das in der Nachricht eingebettet ist), und stelle sicher, dass die Signatur genau die Assertion abdeckt, die dein Code liest; prüfe dann Issuer, Destination, InResponseTo, AudienceRestriction, NotBefore und NotOnOrAfter und weise Replays ab. Die Schwierigkeit ist struktureller Natur. XML Signature signiert Elemente, die per ID referenziert werden, nach der Kanonisierung, sodass ein Dokument ein gültig signiertes Element enthalten kann und daneben ein anderes, unsigniertes, das die Anwendung stattdessen verarbeitet. 2012 wiesen Somorovsky und Kollegen ein solches Signature Wrapping in 11 von 14 SAML-Frameworks nach; 2024 und 2025 brauchte ruby-saml (von GitLab genutzt) erneut Korrekturen (CVE-2024-45409, CVE-2025-25291 und CVE-2025-25292), weil zwei XML-Parser in derselben Bibliothek ein und dasselbe Dokument unterschiedlich lasen.

OpenID Connect (Core §3.1.3.7): Prüfe das JWS mit einem Schlüssel aus dem JWKS des Providers, ausgewählt über kid, und mit dem Algorithmus, den du erwartest; prüfe dann iss, aud (deine Client-ID), exp, iat und die nonce, die du gesendet hast. JSON hat genau einen Parse-Baum, und die Signatur deckt exakt die empfangenen Bytes ab, daher gibt es kein Wrapping-Problem. Als Fallstricke bleiben unerwartete Algorithmen, die akzeptiert werden, ausgelassene Prüfungen von aud und ein zu lockerer Abgleich von Redirect-URIs; genau diese behandelt die Best Current Practice zur Sicherheit von OAuth (RFC 9700, Januar 2025). Der OIDC-Token-Validator führt diese Prüfungen gegen das live abgerufene JWKS eines Providers aus, und der SAML-Inspektor zeigt, welches Element eine Signatur tatsächlich abdeckt.

Wann welches Protokoll passt

• Neue Anwendungen, mobile Apps, Single-Page-Apps, APIs: OpenID Connect mit dem Code-Flow und PKCE.
• SaaS an Unternehmen verkaufen: Unterstütze beide; bei vielen Kunden richten die Teams für Identitätsmanagement noch immer zuerst SAML ein.
• Föderationen in Forschung und Lehre (eduGAIN, InCommon): SAML mit Metadaten-Aggregaten; OpenID Federation 1.0 (final seit Februar 2026) wird für eduGAIN in Pilotprojekten erprobt, ist aber noch nicht die Norm.
• Behörden und regulierte Branchen: Halte dich an das Profil, das dein Ökosystem vorschreibt; Open Banking und ähnliche Regelwerke nutzen FAPI 2.0, ein gehärtetes Profil von OAuth und OpenID Connect.
• Benutzer und Gruppen provisionieren: keines von beiden; nutze SCIM 2.0 (RFC 7643 und RFC 7644) neben dem jeweiligen Protokoll.

Hinweise zur Migration

1. Betreibe beide parallel: Richte im selben Identity Provider eine OIDC-Anwendung ein und ordne vor der Umstellung dieselbe Benutzerkennung (sub oder ein stabiles Attribut) den bestehenden Konten zu.
2. Bilde Attribute explizit auf Claims ab; SAML-Attributnamen (oft URNs) stimmen selten mit den Namen der OIDC-Claims überein, und Gruppen-Claims können einen separaten API-Aufruf erfordern, wenn Nutzer vielen Gruppen angehören.
3. Nutze eine zertifizierte Bibliothek für OpenID Connect, aktiviere Discovery und JWKS-Caching mit Neuladen bei unbekanntem kid und lege die akzeptierten Algorithmen fest.
4. Härte, was bei SAML bleibt: Aktualisiere die Bibliothek, verlange signierte Assertions, weise Dokumente mit mehreren Assertions oder DTDs ab und überwache den Ablauf der Zertifikate in den Metadaten der Partner.
5. Plane den Logout separat: Bilde SAML Single Logout auf OIDC Back-Channel Logout ab, wo Sitzungen zentral enden müssen.
6. Schalte die SAML-Verbindung ab, aber erst, wenn die Logs einen vollen Geschäftszyklus lang keine SAML-Anmeldungen mehr zeigen.

Quellen

• OASIS SAML 2.0 Core und Bindings
• OpenID Connect Core 1.0 (§3.1.3.7, Validierung des ID-Tokens)
• OpenID Connect Discovery 1.0
• OpenID Connect Back-Channel Logout 1.0
• RFC 9700, Best Current Practice zur Sicherheit von OAuth 2.0
• RFC 7636, PKCE und RFC 8252, OAuth für native Apps
• W3C XML Signature Syntax and Processing 1.1
• Somorovsky et al., On Breaking SAML, USENIX Security 2012