SAML ist ein Protokoll für Authentifizierung und Föderation, das Single Sign-On (SSO) für Unternehmen ermöglicht. OAuth 2.0 ist ein Autorisierungsframework, das delegierten Zugriff auf APIs mithilfe von Access Token gewährt.

Authentifizierung und Autorisierung bilden die Grundlage für Identity and Access Management (IAM). Die zugrunde liegenden Protokolle (wie SAML und OAuth 2.0) dienen jedoch unterschiedlichen, wenn auch verwandten Zwecken. Eine Verwechslung dieser Protokolle führt zu Sicherheitslücken und unnötigen Architekturrisiken.

Beispiel: Ihr Unternehmen nutzt Salesforce, Slack und ein internes HR-Portal. Mit SAML melden Sie sich einmalig in Ihrem Unternehmens-Directory an und werden automatisch bei allen drei Diensten authentifiziert (Enterprise SSO). Wenn Sie einem Analysetool eines Drittanbieters Zugriff auf Ihre Salesforce-Daten gewähren möchten, ohne Ihr Passwort preiszugeben, verwenden Sie OAuth 2.0. OAuth 2.0 ermöglicht die delegierte Autorisierung für bestimmte Ressourcen.

SAML 2.0:

• Authentifiziert Benutzer und ermöglicht Enterprise SSO
• Beantwortet die Frage: „Wer ist dieser Benutzer?“
• Verwendet XML-Assertions mit Identity-Attributen
• Ideal für: Enterprise Federation, SSO für Mitarbeiter

OAuth 2.0:

• Autorisiert den Zugriff auf Ressourcen ohne Weitergabe von Anmeldedaten
• Beantwortet die Frage: „Worauf kann dieser Benutzer zugreifen?“
• Stellt Access Token (und optional Refresh Token) für die API-Autorisierung aus
• Ideal für: API-Sicherheit, mobile Apps, Drittanbieterzugriff

OpenID Connect (OIDC) ist eine auf OAuth 2.0 basierende Identity-Ebene, die die Authentifizierung über ID-Token hinzufügt.

Obwohl beide offene Standards sind, unterscheiden sie sich in ihrem Zweck. SAML 2.0 konzentriert sich auf Authentifizierung und SSO und beantwortet die Frage: Wer ist dieser Benutzer? OAuth 2.0 hingegen konzentriert sich auf Autorisierung und beantwortet die Frage: Worauf kann dieser Benutzer zugreifen?

SAML ist für den Identitätsverbund in Unternehmens- und Behördenkontexten konzipiert. OAuth 2.0 ist ein Autorisierungsframework, das für den delegierten Zugriff entwickelt wurde und häufig zur Absicherung moderner APIs und Consumer-Apps eingesetzt wird.

• SAML 2.0 (OASIS-Standard, 2005)
• OAuth 2.0 (IETF RFC 6749, 2012)
• OpenID Connect (OpenID Foundation, 2014)

Aspekt	SAML 2.0	OAuth 2.0
Hauptziel	Authentifizierung und Enterprise SSO	Autorisierung und delegierter Zugriff
Datenformat	XML (Security Assertion)	OAuth 2.0 ist unabhängig vom Token-Format. Die meisten Implementierungen verwenden JWTs, obwohl auch undurchsichtige Token unterstützt werden.
Wichtige Artefakte	Signierte XML-Assertions, Föderationsmetadaten (Out-of-Band)	Access Token, Scopes
Identity-Übertragung	Integriert: Assertions enthalten explizit Identity-Attribute (z. B. Rolle, E-Mail-Adresse).	Nicht integriert: Access Token dienen lediglich dem Autorisierungsnachweis; OpenID Connect fügt Identity-bezogene Claims hinzu.
Implementierung	Unternehmensweite Workforce Identity, Legacy-Systeme	APIs, mobile/native Anwendungen, Microservices
Token-Komplexität	Hoch (XML-Parsing, digitale Signaturen)	Mittel (JWTs erfordern die Validierung von Signaturen, Claims und Schlüssellebenszyklen; undurchsichtige Token erfordern Introspektion)

SAML verwendet XML für seine Security Assertions. XML erfordert zusätzlichen Aufwand für das Parsing und die Signaturvalidierung. Dadurch ergeben sich größere Nachrichten, die die Leistung in Umgebungen mit hohem Durchsatz beeinträchtigen können.

OAuth 2.0 definiert das Token-Format nicht. JSON Web Token (JWTs) sind üblich, aber nicht erforderlich. JWTs sind kompakt und ressourcenschonend und werden im Allgemeinen durch Signaturprüfung, Claim-Validierung und Schlüsselrotation validiert. Dadurch eignen sie sich ideal für mobile Apps und für die Skalierung der API-Autorisierung. Wenn undurchsichtige Token verwendet werden, erfolgt die Validierung nicht anhand von lokalen Signaturprüfungen, sondern mittels Token-Introspektion.

Der entscheidende Unterschied liegt im Nachweis, der vom jeweiligen Kernartefakt des Protokolls erbracht wird.

SAML-Assertions sind direkte Aussagen über die Identität und Attribute eines Benutzers, die von einem Identity-Anbieter ausgestellt werden. Eine Anwendung kann darauf vertrauen, dass die Assertion die Identität des Benutzers und die Gruppe, der er angehört, bestätigt.

OAuth 2.0-Access-Token belegen lediglich die Autorisierung für den Zugriff auf bestimmte Ressourcen. Sie sind kein Identitätsnachweis. Die alleinige Verwendung von OAuth 2.0 zur Authentifizierung ohne eine Erweiterung wie OIDC erzeugt eine Sicherheitslücke, da das Access Token die Identität des Benutzers nicht verifiziert.

Die Protokolle unterscheiden sich grundlegend in ihren Abläufen:

• SAML betont das zuvor hergestellte Vertrauen durch den Austausch von Metadaten und gibt Identity-bezogene Daten direkt in signierten XML-Assertions über Browser-Weiterleitungen zurück.
• OAuth 2.0 verwendet Autorisierungscodes als Zwischenschritt, wobei der Client an einem Backend Endpoint die Codes gegen Token tauscht, um eine sichere Übermittlung der Token zu ermöglichen, ohne dass diese im Browser offengelegt werden.

SAML verwenden Sie für folgenden Zwecke:

Enterprise SSO-Anforderungen

• Zentralisiertes Identity-Management
• Nahtloses SSO über mehrere Geschäftsanwendungen hinweg
• Austausch von angereicherten Benutzerattributen (Abteilung, Rolle, Gruppen)

Einhaltung gesetzlicher Bestimmungen

• Integrierte Attributanweisungen für Überprüfbarkeit und Governance
• Explizite Freigabe von Identity-bezogenen Daten für Compliance-Berichte

Enterprise und Government Federation
SAML wird in großem Umfang für den Identitätsverbund in Unternehmen und Behörden verwendet, einschließlich moderner Unternehmensplattformen und Legacy-Systeme. Identity-Plattformen für Unternehmen und Behörden unterstützen typischerweise sowohl SAML als auch OIDC, um unterschiedlichen Integrationsanforderungen gerecht zu werden.

OAuth 2.0 verwenden Sie für folgende Aufgaben:

API-Sicherheit

• Schutz von REST-APIs mithilfe von Scopes (Berechtigungsbereichen) für granulare Zugriffskontrolle
• Neutrale Autorisierung für Microservices
• Token-basierte API-Sicherheit

Mobile und native Anwendungen

• Ressourcenschonendes JSON-Format und Autorisierungscode mit Proof Key for Code Exchange (PKCE)
• Sichere Browser-basierte Weiterleitungen mithilfe von Systembrowsern anstelle von eingebetteten webbasierten Ansichten

Drittanbieterzugriff

• Delegieren spezifischer Berechtigungen ohne Weitergabe von Anmeldedaten
• Social Login (Anmeldung mit Google, Facebook)
• Begrenzter Scope-basierter Zugriff auf Benutzerdaten

OIDC ist eine Identity-Ebene, die auf OAuth 2.0 aufbaut. Das Protokoll nutzt ID-Token für die Benutzerauthentifizierung und standardisiert die Darstellung von Identity-Claims, während Access Token für die API-Autorisierung weiterhin mit OAuth 2.0 ausgestellt werden. OIDC ersetzt OAuth 2.0 nicht, sondern erweitert es mit der Unterstützung für Authentifizierung und Identity-Management. In modernen Abläufen übernimmt OIDC die Authentifizierung (Ausstellung von ID-Token), während OAuth 2.0 die Autorisierung übernimmt (Ausstellung von Access Token für API-Aufrufe). Beide arbeiten typischerweise im selben Ablauf zusammen.

Feature	OAuth 2.0	OIDC (OAuth 2.0-Erweiterung)
Primäre Ausgabe	Access Token (Autorisierung)	ID-Token (Authentifizierung)
Identitätsprüfung	Nein (nur Autorisierung)	Ja (Identity-Claims, Benutzerprofil)

1. Nutzung von OAuth 2.0 zur Authentifizierung

• OAuth 2.0-Access-Token dienen als Autorisierungsnachweis, nicht als Identitätsnachweis.
• Verwenden Sie OpenID Connect zur Authentifizierung oder implementieren Sie zusätzliche Verifizierungsmaßnahmen.

2. Unzureichende Token-Validierung

• SAML: Signaturen validieren, Ablaufbedingungen (NotBefore/NotOnOrAfter) prüfen, Zielgruppe prüfen
• OAuth 2.0: Signatur, Ablaufdatum (exp), Zielgruppe (aud), Aussteller (iss) und optional Gültigkeit nicht vor (nbf) validieren
• Die Validierungsmethode hängt vom Token-Typ ab: JWT lokal verifizieren oder Introspektion für undurchsichtige Token verwenden

3. Nutzung von unsicheren Abläufen für öffentliche Clients

• Native Anwendungen können Client Secrets nicht sicher speichern (d. h. sie sind „öffentliche“ Client Secrets).
• Verwenden Sie den Autorisierungscode-Ablauf mit PKCE für öffentliche Clients, um das Abfangen von Autorisierungscodes zu verhindern. (Abläufe ohne PKCE, wie der implizite Gewährungsablauf, sind veraltet und sollten in allen Neuentwicklungen vermieden werden.)

Was ist der Hauptunterschied zwischen SAML und OAuth 2.0?

SAML wird zur Authentifizierung (Bestimmung der Identität des Benutzers) und OAuth 2.0 zur Autorisierung (Festlegung, worauf der Benutzer zugreifen kann) verwendet. SAML wird für Enterprise SSO und OAuth 2.0 für die API-Zugriffskontrolle verwendet.

Kann OAuth 2.0 SAML für SSO ersetzen?

OAuth 2.0 allein kann SAML für SSO nicht ersetzen, da es sich um ein reines Autorisierungsframework handelt. OIDC (basierend auf OAuth 2.0) fügt die erforderliche Authentifizierungsebene für SSO hinzu, im Gegensatz zu SAML sind die Single-Logout-Spezifikationen jedoch eine optionale Erweiterung, die von der Implementierung separat behandelt wird.

Welches Protokoll ist sicherer?

Beide Protokolle bieten bei korrekter Implementierung starke Sicherheitsgarantien. Risiken ergeben sich aus Implementierungsfehlern, wie fehlender Signaturvalidierung, unsachgemäßer Handhabung der Token-Lebensdauer, schwachen Zielgruppen- und Ausstellerprüfungen oder falsch konfigurierten Autorisierungs-Endpoints. SAML bietet Signaturen auf Nachrichtenebene und optionale Verschlüsselung. OAuth 2.0 in Kombination mit PKCE und ordnungsgemäßer Token-Validierung ist aber genauso sicher. Protokolle sollten primär danach ausgewählt werden, wie gut sie in die Architektur passen, und erst an zweiter Stelle nach vermeintlichen Sicherheitsvorteilen.

Muss ich beide Protokolle unterstützen?

Die meisten Anwendungen benötigen intern nicht beide Protokolle. Möglicherweise müssen Sie jedoch beide unterstützen, wenn Sie externe Identity-Anbieter integrieren. Unternehmenskunden fordern häufig SAML, während Consumer-Apps Social Login per OAuth 2.0 erwarten. Identity-Plattformen übernehmen die Protokollübersetzung.

Warum bevorzugen APIs OAuth 2.0 gegenüber SAML?

APIs bevorzugen OAuth 2.0, da Token kleiner und einfacher zu parsen sind als XML-Assertions, die Scope-basierte Autorisierung direkt den API-Berechtigungen zuordnet wird und moderne Programmiersprachen besseren Support für OAuth 2.0-Bibliotheken bieten.

Die Wahl zwischen SAML und OAuth 2.0 hängt von Ihren Anwendungsanforderungen und Integrationsszenarien ab. Beide Protokolle gewährleisten bei korrekter Implementierung sicheres Identity and Access Management (IAM).

Die Verwendung einer Identity-Plattform wie Auth0 reduziert die Komplexität der Protokolle, SAML, OAuth 2.0 und OpenID Connect unterstützt werden. Ihre Anwendung authentifiziert Benutzer über eine konsistente API, unabhängig vom zugrunde liegenden Protokoll. Vertiefen Sie Ihr Verständnis von Identity-Protokollen und modernen Authentifizierungsarchitekturen in unserer Reihe „Einführung in IAM“.

Mehr erfahren

Diese Materialien dienen nur zur allgemeinen Information. Es liegt in Ihrer Verantwortung, sich mit Blick auf Sicherheit, Datenschutz, Compliance oder geschäftliche Angelegenheiten beraten zu lassen und sich nicht ausschließlich auf die hierin bereitgestellten Informationen zu verlassen.