SAML und OAuth2 sind Open-Standard-Protokolle, die zu unterschiedlichen, aber dennoch zusammenhängenden Zwecken entwickelt wurden. SAML 2.0 wurde in erster Linie dazu entwickelt, einen Nutzer zu authentifizieren, d. h., Daten zur Nutzeridentität an einen Dienst zu übermitteln. OAuth 2.0 wurde als Autorisierungsprotokoll entwickelt, das es Nutzern ermöglicht, gemeinsam auf bestimmte Ressourcen bei einem Serviceprovider zuzugreifen.

SAML (Security Assertion Markup Language) ist ein bewährtes, sicheres Protokoll, das vor allem von Unternehmen und Regierungen dazu genutzt wird, Identitätsdaten zu teilen. Diese Daten nutzen XML-Strukturen und Simple HTTP oder SOAP für die Datenübertragung. Über SAML stellt ein Identitätsanbieter (IdP) auf Anfrage Nutzerdaten (Attribute wie Namen, E-Mail usw.) an einen Dienst oder eine Relying Party (RP) bereit.

Bevor eine Authentifizierung stattfindet, müssen die Relying Party (RP) und der Identitätsanbieter (IdP) eine Vertrauensbeziehung aufbauen. Diese Beziehung beruht auf dem Austausch bestimmter Artefakte, z. B. von Metadaten, bestimmten Endpunkten, Signaturen und Verschlüsselungszertifikaten, unterstützten Verbindungsmethoden usw.

Sobald diese Elemente festgelegt wurden, sendet die RP, die die Identität eine Nutzers benötigt, in einer Browsersitzung einen Form-POST (oder ein Redirect) mit einer Authentifizierungsanfrage an den IdP. Der IdP authentifiziert den Endnutzer mit einem interaktiven Login und sendet die entsprechenden Identitätsdaten (die Anmeldedaten) über einen Form-POST per SAML-Antwort zurück an die RP. Diese Identitätsdaten enthalten immer einen Identifikator, über den die RP den Nutzer identifizieren kann. Als Bestandteil dieser Interaktion kann der IdP auch eine Single-Sign-on-Sitzung (SSO) einrichten, sodass bei Authentifizierungsanfragen anderer RPs der interaktive Anmeldeschritt übersprungen werden kann.

Benötigt die RP zusätzliche Attribute, können diese im Rahmen der SSO-Sitzung über eine Attributanfrage beim IdP abgefragt werden.

In der Regel sind SAML-Antworten digital signiert, um Datenmanipulationen während der Übertragung zu erkennen. Ist die Verschlüsselung bei der Übermittlung nicht ausreichend (HTTPS), kann eine zusätzliche Verschlüsselung erfolgen.

OAuth 2.0 wurde 2012 erstmalig veröffentlicht und ist auch unter der Bezeichnung OAuth2 bekannt. Es handelt sich dabei um ein Autorisierungsprotokoll, mit dem es Nutzern ermöglicht wird, Zugriff auf ihre bei einem Serviceprovider gehosteten Ressourcen zu gewähren, ohne Anmeldedaten preiszugeben. Die Art der Nutzerressourcen wird in den Protokollspezifikationen nicht definiert, es kann sich also um Daten oder andere Instanzen handeln. OAuth2 bietet einen umfassenden Funktionsumfang, der die Nutzung durch eine Vielzahl von Geräten und Anwendungen ermöglicht. Darüber hinaus ist OAuth2 die Entwicklungsbasis für OpenID Connect, ein beliebtes Authentifizierungsprotokoll.

In der Terminologie von OAuth2 wird der Dienst, der den Zugriff auf Nutzerressourcen benötigt, als Client bezeichnet, der Dienst, der diese Ressourcen bereitstellen kann, als Ressourcenserver. Der Zugriff auf Nutzerressourcen, die vom Ressourcenserver geführt werden, wird über sogenannte Zugriffstokens geregelt , d. h. Artefakte, die die Zugriffsautorisierung nachweisen. OAuth2 umfasst außerdem einen Mechanismus namens Scope, der die Berechtigungen bei einer Nutzerressource einschränkt.

Das System, das den Nutzer authentifiziert und letztlich mit Zugriffstokens antwortet, ist der Autorisierungsserver.

Wie bei SAML müssen auch bei OAuth2 der Client und der Ressourcenserver bestimmte Daten mit dem Autorisierungsserver austauschen. Dabei wird mindestens eine Client-ID und ein Client Secret vom Autorisierungsserver bezogen und die Endpunkte, um spezifische Informationen zu erhalten, werden vereinbart.

OAuth2 ist sehr flexibel und erteilt dem Client eine Reihe von als Grant bezeichneten Flows, um ein Zugriffstoken zu erhalten. Welche Genehmigung infrage kommt, hängt in erster Linie von der Art des Clients (mobile App, native App, Web-Client usw.) und den allgemeinen Sicherheitsanforderungen ab. Am häufigsten ist vielleicht die Erteilung eines Autorisierungscodes, der zum Tragen kommt, wenn die Client-Anwendung, die auf die Nutzerressource zugreifen will, eine reguläre Web-App ist. Im Folgenden werden die Interaktionen zwischen Client, Ressourcenserver und Autorisierungsserver kurz beschrieben:

1. Der Client leitet den Nutzer an den Autorisierungsserver weiter, um den Zugriff auf die Nutzerressource innerhalb eines bestimmten Umfangs (Scope) anzufordern.

2. Der Autorisierungsserver führt eine interaktive Anmeldung mit dem Nutzer durch, der außerdem bestätigt, dass er für die angegebenen Scopes die Berechtigungen erteilt.

3. Der Autorisierungsserver leitet den Nutzer mit einem einmaligen Autorisierungscode an den Endpunkt des Clients weiter.

4. Der Client authentifiziert sich bei dem Autorisierungsserver und tauscht den Autorisierungscode gegen ein Zugriffstoken um.

5. Mit diesem Zugriffstoken fragt der Client die Nutzerressource beim Ressourcenserver an.

SAML unterstützt neben Single Sign-on auch die Autorisierung über die Abfrage von Attributen. OAuth konzentriert sich auf die Autorisierung, auch wenn der Dienst häufig für die Authentifizierung genutzt wird, beispielsweise bei der Anmeldung über soziale Medien, z. B. ein Facebook-Konto. Trotzdem unterstützt OAuth2 SSO nicht.

Aus technischer Sicht definiert SAML ein Tokenformat, die Verschlüsselung ist kompliziert und die Größe der ausgetauschten Nachrichten ist beträchtlich. Im Gegensatz dazu nutzt OAuth2 keinerlei Verschlüsselung der Nachrichten (und verlässt sich hier auf HTTPS) und definiert kein Tokenformat.

Der Reiz von OAuth2 liegt in seiner Benutzerfreundlichkeit und Flexibilität. Es kann auf mobilen Geräten, Smartgeräten (z. B. Smart-TVs), Web-Apps, einseitigen Apps usw. genutzt werden. Die vielen verfügbaren Bibliotheken erleichtern die Integration in unterschiedliche Arten von Clients und Serviceprovider. Bei der Entwicklung von SAML lagen solche modernen Anwendungen noch in ferner Zukunft. Somit ist es schwieriger, SAML mit diesen Systemen zu nutzen. Daher wird es häufig bei traditionellen Web-Apps genutzt.

SAML wird häufig für das SSO bei Anwendungen im öffentlichen Sektor und in Unternehmen genutzt (Identitätsmanagement), in denen die Backend-Systemverarbeitung von XML üblich ist. Viele Bürgeridentifikationssysteme des öffentlichen Sektors (z. B. UK Verify) basieren auf SAML.

OAuth2 kommt überwiegend in Verbraucher- und Unternehmensanwendungen für die Autorisierung und die Authentifizierung zum Einsatz. Es wird in der Regel für die Autorisierung des Zugriffs auf RESTful APIs genutzt, wo es dank der Verwendung von Zugriffstokens einfach und attraktiv ist.

Lesen Sie unsere Einführung in IAM, um sich über weitere Themen rund um das Identitäts- und Zugriffsmanagement zu informieren.