OIDC und SAML im Vergleich

OpenID Connect (OIDC) und Security Assertion Markup Language (SAML) sind Authentifizierungsprotokolle, mit denen ein Identitätsanbieter (Identity Provider, IdP) Benutzervalidierung und Zugriffskontrolle implementieren kann. Die Mechanismen zur Verwaltung der virtuellen Identitäten verifizierter Benutzer, die dann verwendet werden, um den Zugriff auf geschützte Anwendungen zu gewähren oder abzulehnen, unterscheiden sich je nach Protokoll.

Ein IdP verwaltet eine Datenbank mit Benutzeridentitätsinformationen. Ein Serviceanbieter (Service Provider, SP) nutzt diese Informationen, um Benutzer zu authentifizieren – unter Umständen sogar nur einmal für mehrere Anwendungen (Single Sign-on, SSO). OIDC und SAML sind Standards, die genau vorgeben, wie diese Informationen zwischen den beiden Parteien fließen sollen. Das Ziel ist bei beiden dasselbe: Benutzerauthentifizierung. Dieses Ziel wird jedoch mit jeweils anderen Methoden erreicht.

Bei der Authentifizierung wird die Identität eines Benutzers oder eines Prozesses überprüft. Dies geschieht in der Regel, um den Zugriff auf geschützte Anwendungen und/oder Ressourcen zu beschränken.

SAML 2.0, die aktuelle Version des Standards, gibt es bereits seit 2005. Dabei wird XML als Format für Identitätsinformationen verwendet. XML ist ein etablierter Standard für die Formatierung von Informationen, bei dem Dokumente so codiert werden, dass sie sowohl für Menschen als auch für Computer leicht verständlich sind. Für die Übertragung oder den Empfang von XML-codierten Informationen werden einfache SOAP- oder HTTP-Anfragen genutzt. Der Service, der Identitätsinformationen anfordert, wird im SAML-Vertrag als Serviceanbieter (SP) definiert. So sieht der typische Datenfluss bei der SAML-Authentifizierung aus:

1. Bevor der SP mit dem IdP zur Identitätsverifizierung kommunizieren kann, müssen sich die beiden Parteien zunächst besser kennenlernen. Dazu tauschen sie vorab über Metadaten Informationen aus, die beispielsweise Folgendes umfassen:

   • Öffentliche Schlüssel (für die Verschlüsselung verwendet)

   • Unterstützte Verschlüsselungsalgorithmen

   • Endpunkt-URLs (Ziel der SAML-Nachrichten)

   • Unterstützte Verbindungsmethoden

   • Unterstützte XML-Attributformate

Sobald dem SP und dem IdP diese Einzelheiten bekannt sind, erfolgt eine entsprechende Neukonfiguration.

2. Wenn ein Benutzer versucht, sich anzumelden, sendet der SP eine Authentifizierungsanfrage an den IdP. Diese Anfrage wird bei SAML als AuthnRequest bezeichnet.

3. Der IdP prüft die Benutzeridentität, erstellt eine verschlüsselte SAML-Antwort (bei SAML als Assertion bezeichnet) und sendet sie an den SP zurück.

4. Der SP verarbeitet die SAML-Assertion-XML und gewährt oder verweigert dem Benutzer auf der Grundlage der Antwort den Zugriff auf die Anwendung.

OIDC ist ein neueres, aber gängiges Protokoll, das auf dem OAuth 2.0-Framework aufbaut. Bei OIDC werden JSON-basierte Web-Token (JWT) zur Strukturierung von Daten verwendet. JWT ist ein Branchenstandard, der die Regeln für die Darstellung und sichere Übertragung von sogenannten Claims (Forderungen) zwischen zwei Parteien definiert. Sie können sich Claims als verschlüsselte, sensible Benutzerdaten vorstellen, die zur Unterstützung von Identity Management und Verifizierung verwendet werden. Für den Transport kommen bei OIDC standardmäßige HTTPS-Datenflüsse zum Einsatz.

Scopes (Geltungsbereiche) geben bei OIDC vor, auf welche Claims (Benutzerattribute) eine Anwendung Zugriff erhalten kann. Der IdP verwaltet eine Liste der akzeptablen Scopes. Von den Anwendungen wird je nach Bedarf ausgewählt, welche Scopes angefordert werden sollen. Nachdem ein Benutzer ausdrücklich der Weitergabe seiner Daten (einschließlich der Scopes) zugestimmt hat, stellt der IdP die Scopes der Anwendung zur Verfügung.

Um besser zu verstehen, wie Scopes in einem typischen OIDC-Datenfluss funktionieren, betrachten wir eine Webanwendung, die einen Benutzer anhand seines Benutzernamens und seines Kennworts authentifiziert. Nach der Authentifizierung erhält der Benutzer eine Reihe von Begrüßungs-E-Mails.

(Hinweis: OIDC unterstützt verschiedene Authentifizierungsdatenflüsse. Nachfolgend sehen Sie ein Beispiel für den einfachsten OIDC-Datenfluss, den so genannten impliziten Datenfluss.)

1. Genau wie bei SAML müssen die Relying Party (RP) und der IdP Metadaten austauschen, bevor sie miteinander kommunizieren können. Bei OIDC gelten jedoch geringere Mindestanforderungen an den Austausch von Metadaten. Beide Parteien müssen sich auf mögliche Scopes einigen. Der IdP muss dem RP ein Secret (geheimer Schlüssel) und eine Client-ID zuweisen. Die RP muss den Endpunkt für den Erhalt von Codes und/oder Token angeben.

2. Wenn sich ein Benutzer bei der Anwendung anmeldet, wird er von der Anwendung an den IdP weitergeleitet. Mitgesendet werden die Client-ID und die angeforderten Scopes – in unserem Fall die E-Mail-Adresse des Benutzers.

3. Der IdP wiederum leitet den Benutzer zum Anmeldebildschirm weiter.

4. Sobald die Identität des Benutzers erfolgreich verifiziert wurde, wird er aufgefordert, der Anwendung Zugriff auf seine Daten zu gewähren (festgelegt durch die angeforderten Scopes).

5. Wenn der Benutzer Zugriff gewährt, werden die Scope-Werte über den vorkonfigurierten Endpunkt der Anwendung zur Verfügung gestellt.

6. Die Anwendung kann nun die Begrüßungssequenz an die E-Mail-Adresse des Benutzers senden.

• SAML ist als älterer Standard kaum für die Authentifizierung moderner Anwendungstypen wie Single-Page-Anwendungen (SPAs) und Smartphone-Anwendungen geeignet. Darauf ist er nicht ausgelegt. Dagegen eignet sich OIDC ideal für Anwendungen dieser Art.

• Bei OIDC werden JWTs verwendet, die eine geringere Größe haben und keine hohen Anforderungen an die Verarbeitung stellen. Die bei SAML verwendeten XML-Dokumente sind viel größer und daher aufwendiger zu verarbeiten.

• OIDC unterstützt eine standardmäßige Zustimmung der Benutzer. Das Gleiche kann mit SAML erreicht werden, erfordert aber eine umfangreiche manuelle Entwicklung.

• Da es SAML schon viel länger gibt, wird das Protokoll immer noch von vielen Unternehmen und Einrichtungen genutzt, darunter auch staatliche Stellen. Es ist sicherlich funktionsreicher, aber OIDC beginnt jetzt aufzuholen.

• OIDC ist viel einfacher einzurichten, insbesondere in einer verbraucherzentrierten Umgebung, in der die grundlegenden Identitätsmerkmale erforderlich sind.

OIDC wurde als moderner Ersatz für SAML konzipiert, da es die meisten der grundlegenden SAML-Anwendungsfälle nachbildet und gleichzeitig den durch XML- und SOAP-basierte Nachrichten verursachten Verarbeitungsaufwand reduziert. Die meisten Sicherheitsmängel sind nicht auf intrinsische Probleme bei einem der beiden Standards zurückzuführen, sondern auf Implementierungsfehler. Man kann jedoch argumentieren, dass SAML, da es viel schwieriger zu implementieren ist als OIDC, auch anfälliger für Implementierungsfehler ist. Darüber hinaus gibt es viele Sicherheitsbedrohungen und Schwachstellen im Zusammenhang mit XML, die bei der SAML-Implementierung vermieden werden müssen, was die Komplexität noch erhöht.

Da OIDC auf OAuth 2.0 basiert, wurden bereits viele der dokumentierten Bedrohungsmodelle und Sicherheitsüberlegungen berücksichtigt. Die Verschlüsselung ist bei JSON wesentlich einfacher als bei XML, was die Wahrscheinlichkeit von Implementierungsfehlern verringert.

Über die Scopes können Benutzer bei OIDC auswählen, in welchem Umfang sie Informationen mit einer Anwendung teilen möchten. Eine Anwendung fordert Benutzer dann beispielsweise nur zur Freigabe ihrer E-Mail-Adresse auf und nicht zur Freigabe ihres gesamten Profils. Auf diese Weise entsteht ein Vertrag zwischen dem Benutzer und der Anwendung, von dem beide Seiten profitieren: Die Anwendung erhält das, was sie braucht, um das Benutzererlebnis zu verbessern, und die Benutzer müssen nur ein Minimum an persönlichen Daten preisgeben. Diese Funktion kann auch zu SAML-basierten Systemen hinzugefügt werden, würde dort aber eine zusätzliche Entwicklung erfordern, da SAML sie nicht von Haus aus unterstützt.

OIDC und SAML können gleichermaßen zur Implementierung von Single Sign-on (SSO) verwendet werden, wodurch die Notwendigkeit einer mehrfachen Anmeldung und damit die Wahrscheinlichkeit von Phishing-Angriffen verringert wird. Trotz der geringeren Wahrscheinlichkeit können solche Angriffe aber durchaus erfolgen. Mit Cofense Phishing Defense Center wurde eine Phishing-Taktik aufgedeckt, bei der OIDC so manipuliert wurde, dass Benutzerdaten trotz Multi-Faktor-Authentifizierung ohne Kennwort offengelegt wurden. Ähnliche Phishing-Angriffe gab es in der Vergangenheit auch bei SAML-Implementierungen. Es ist schwer zu sagen, ob das eine Protokoll Phishing besser verhindert als das andere. Vieles hängt von den Sicherheitsüberlegungen ab, die bei der Implementierung angestellt werden.

OIDC und SAML können gleichermaßen zur Implementierung von Single Sign-on (SSO) verwendet werden. Das bedeutet, dass sich Benutzer nur ein Kennwort merken müssen, um sich beim Identity and Access Management (IAM) anzumelden. Die entsprechenden Anmeldedaten können auch dadurch geschützt werden, dass die Benutzer einen zusätzlichen Authentifizierungsfaktor angeben müssen. Sobald die Benutzer sicher beim IAM-Service angemeldet sind, können sie nahtlos auf alle geschützten Anwendungen zugreifen, ohne weitere Kennwörter eingeben zu müssen. Dies ist wichtig, um Brute-Force-Angriffe zu verhindern, bei denen Angreifer viele potenzielle Kennwörter nacheinander eingeben und hoffen, einen Treffer zu landen. Wenn es keine Kennwörter gibt, ist auch kein Brute-Force-Angriff möglich.

OIDC und SAML sind zwei leistungsstarke Authentifizierungstechnologien mit einzigartigen Funktionen. Welche Sie für Ihr Unternehmen wählen, hängt von Ihren spezifischen Anforderungen ab. Grundsätzlich gilt:

• Wenn Sie schnell eine Identitätsplattform einrichten möchten, ist OIDC immer die bessere Wahl als SAML. Die Implementierung einer grundlegenden OIDC-Lösung ist im Vergleich zu SAML, das eine umfangreiche XML-Verarbeitung erfordern würde, viel einfacher.

• Wenn Sie eine API-zentrierte Architektur mit vielen mobilen und Single-Page-Anwendungen haben, ist OIDC das passende Protokoll. Es sorgt für eine viel effizientere und besser interoperable Erfahrung.

• Wenn Sie Wert auf einen ausgereiften Standard legen, den es schon lange gibt, sind Sie bei SAML richtig. Es ist funktionsreich, erfüllt seinen Zweck und ist seit über einem Jahrzehnt ein fester Bestandteil von Unternehmensnetzwerken.