OAuth oder SAML: Welches Protokoll passt zu Ihnen?

OAuth und SAML lösen unterschiedliche Probleme, und genau deshalb führt ein direkter Vergleich leicht in die Irre. SAML meldet eine Person über einen zentralen Identitätsanbieter bei einer Anwendung an, meist im unternehmensweiten Single Sign-on. OAuth 2.0 verschafft einer Anwendung begrenzten Zugriff auf die API eines anderen Dienstes, im Namen einer Nutzerin oder eines Nutzers. Wer von «OAuth-Login» spricht, meint in der Regel OpenID Connect (OIDC), eine schlanke Identitätsschicht auf OAuth. Die eigentliche Frage lautet für die meisten Teams also: SAML oder OIDC für die Anmeldung, und OAuth für den API-Zugriff.

Nachfolgend klären wir, was die einzelnen Protokolle leisten, worin sie sich in der Praxis unterscheiden, wie Sie entscheiden und was sich ändert, wenn Ihre Nutzer:innen und Daten in der Schweiz liegen.

Kurz zusammengefasst

• Bei OAuth 2.0 geht es um Autorisierung: Es beantwortet die Frage «Darf diese Anwendung jene API aufrufen, und mit welchem Umfang?» Wer die Nutzerin oder der Nutzer ist, sagt es nicht.
• Bei SAML 2.0 geht es um föderierte Anmeldung: ein XML-basierter Standard für Browser-SSO, in vielen grossen Konzern- und Altsystem-Umgebungen nach wie vor der Normalfall.
• OIDC ist OAuth plus Identität: Es ergänzt ein ID-Token und liefert damit eine standardisierte Authentifizierung. Für neue Web-, Mobile- und API-getriebene Produkte ist es meist die bessere Wahl.
• Unterstützen Sie beides, wenn Ihre Kundschaft aus Unternehmen oder Behörden besteht: Die Identitätsdienste des Bundes akzeptieren sowohl OIDC als auch SAML 2.0.
• Das Protokoll klärt Ihre rechtlichen Pflichten nicht: Nach dem Schweizer Datenschutzgesetz (DSG) muss weiterhin begründet sein, was Sie nach der Anmeldung mit Personendaten tun.

Was die einzelnen Protokolle wirklich leisten

Am schnellsten lassen sich die drei Begriffe über die Frage trennen, die jeder von ihnen beantwortet. One practical comparison bringt es auf den Punkt: OAuth beantwortet, ob eine Anwendung eine API aufrufen darf, OIDC beantwortet, wer sich angemeldet hat, und SAML regelt die föderierte Anmeldung zwischen Identitätsanbieter und Anwendung.

OAuth 2.0: delegierter Zugriff

OAuth 2.0 ist in RFC 6749 definiert. Seine Aufgabe ist es, einer Anwendung begrenzten Zugriff auf eine geschützte Ressource zu verschaffen, entweder für eine Nutzerin oder im eigenen Namen. Denken Sie an ein Terminplanungstool, das Ihren Kalender liest, oder an einen Backend-Dienst, der die API eines anderen Unternehmens aufruft. Das Passwort gelangt nie zur Drittanwendung. Stattdessen erhält die Anwendung ein Zugriffstoken mit festgelegtem Umfang und begrenzter Gültigkeit.

Entscheidend ist: Ein Zugriffstoken ist ein Berechtigungsschein, kein Ausweis. Wer «ich habe ein gültiges Token» mit «ich weiss, wer das ist» gleichsetzt, baut früher oder später eine Sicherheitslücke ein. Dieser Fehler ist verbreitet, und genau darum gibt es OIDC.

Der Standard entwickelt sich zudem weiter. Der OAuth 2.1 draft der IETF löst laut Beschreibung RFC 6749 und das Dokument zur Verwendung von Bearer-Tokens ab, war in der von uns geprüften Fassung aber noch ein Internet-Draft. Die praktische Empfehlung bleibt heute dieselbe: Verwenden Sie den Authorization-Code-Flow mit PKCE und verzichten Sie auf die alten Verfahren.

OpenID Connect: OAuth mit Anmeldung

OIDC nutzt die Abläufe von OAuth 2.0 und ergänzt ein standardisiertes ID-Token, ein signiertes JSON Web Token mit Angaben dazu, wer sich wie authentifiziert hat. Es arbeitet mit JSON und einfachen REST-Aufrufen, was zu Single-Page-Anwendungen, nativen Mobile-Apps und API-zentrierten Systemen passt. Wenn Entwickler:innen sagen «wir melden uns per OAuth mit Google an», meinen sie fast immer OIDC.

SAML 2.0: das Arbeitspferd im Unternehmens-SSO

SAML 2.0 ist ein XML-basierter Standard. Ein Identitätsanbieter (IdP) stellt eine signierte Aussage über die Person aus, und der Diensteanbieter (SP), also Ihre Anwendung, vertraut ihr. Der Austausch läuft über Browser-Weiterleitungen und POST-Bindings. Der Standard stammt aus der Zeit vor dem Mobilzeitalter, und das merkt man: SAML ist um einen Browser und eine Sitzung herum gebaut, nicht um eine native App oder eine Maschine, die eine API aufruft.

Gleichzeitig ist SAML tief verankert. Unternehmensverzeichnisse, HR-Systeme und viele ältere SaaS-Produkte sprechen weiterhin SAML, und IT-Abteilungen in Konzernen fragen oft ausdrücklich danach.

OAuth und SAML im Überblick

	OAuth 2.0	OIDC	SAML 2.0
Hauptzweck	Autorisierung (API-Zugriff)	Authentifizierung auf Basis von OAuth	Authentifizierung und SSO
Datenformat	JSON, undurchsichtige oder JWT-Tokens	JSON, JWT-ID-Token	XML-Assertions
Typische Clients	APIs, Mobile, SPAs, Dienste	Web, Mobile, SPAs	Browserbasierte Webanwendungen
Sagt es, wer die Person ist?	Allein nicht	Ja	Ja
Eignung für Mobile und APIs	Hoch	Hoch	Gering
Wo es Ihnen begegnet	Integrationen mit Drittanbietern	Modernes Login, Consumer und B2B	Unternehmens-SSO, ältere Suiten
Aufwand für die Umsetzung	Mittel	Mittel	Höher, XML-Signaturen und Metadaten

Die Zeile, die Sie sich merken sollten, ist die vierte. OAuth allein authentifiziert nicht. SAML und OIDC schon.

So entscheiden Sie: ein Entscheidungsweg

Fragen Sie nicht «was ist besser», sondern was Sie bauen und wer sich damit verbindet.

1. Nutzer:innen sollen sich bei Ihrem neuen Produkt anmelden. Nehmen Sie OIDC. Kombinieren Sie es mit einem Identitätsanbieter oder einer Bibliothek, der Sie vertrauen, statt die Token-Verarbeitung selbst zu schreiben.
2. Ihre Anwendung soll im Namen der Nutzer:innen eine fremde API aufrufen. Nehmen Sie OAuth 2.0 mit Authorization Code und PKCE und fordern Sie die engsten möglichen Berechtigungen an.
3. Die IT-Abteilung einer Kundin sagt «wir nutzen SAML». Bieten Sie SAML 2.0 als Unternehmens-SSO an. Viele B2B-Produkte starten mit OIDC und ergänzen SAML, sobald die erste grosse Kundin danach fragt.
4. Sie verbinden Dienste miteinander, ohne dass eine Person beteiligt ist. Nehmen Sie OAuth 2.0 mit Client Credentials, nicht SAML.
5. Sie müssen an einen staatlichen oder eidgenössischen Identitätsdienst anbinden. Prüfen Sie zuerst, was unterstützt wird, und lesen Sie die Spezifikation. Mehr dazu weiter unten.

Ist OAuth 2.0 überholt?

Nein. OAuth 2.0 bleibt die Grundlage moderner API-Autorisierung, und OAuth 2.1 fasst bewährte Praxis zusammen, statt das Konzept zu ersetzen. Überholt sind einige ältere Muster: der Implicit Flow und der Password Grant. Wenn eine Anleitung diese empfiehlt, suchen Sie sich eine neuere.

Stirbt SAML aus?

So bald nicht. Es ist ein ausgereifter Standard, der funktioniert, und ihn in grossen Organisationen zu ersetzen, ist teuer und bringt kaum sichtbaren Nutzen. Für Neuentwicklungen ist OIDC der einfachere Weg. Wer an Unternehmen verkauft, braucht SAML-Unterstützung weiterhin als Verkaufsargument, nicht als Kuriosität aus alten Zeiten.

Ein häufiger Architekturfehler: Berechtigungen ins Login packen

Identität und Zugriff sind zwei verschiedene Aufgaben. Die Authentifizierung sagt, wer Sie sind. Die Zugriffsverwaltung entscheidet, was Sie innerhalb einer bestimmten Anwendung tun dürfen. Probleme entstehen, wenn Teams jede Rolle und jede Berechtigung durch das Identitätsprotokoll schleusen wollen.

Die Dienste des Bundes trennen das ausdrücklich. AGOV, der Authentifizierungsdienst für Schweizer Behörden, liefert Identitäten und Authentifizierung über OIDC oder SAML, kümmert sich aber nicht um Rollen oder Berechtigungen. Die angebundene Anwendung muss ihre Zugriffsverwaltung selbst umsetzen. Das ist für jedes Produkt gutes Design: eine geprüfte Identität entgegennehmen und sie dann im eigenen System auf Rollen und Berechtigungen abbilden, wo Sie diese ändern können, ohne den Identitätsanbieter anzufassen.

Ein bewährtes Muster:

• Übernehmen Sie eine stabile Benutzerkennung und wenige Attribute aus dem ID-Token oder der SAML-Assertion.
• Suchen oder erstellen Sie die Person in Ihrer eigenen Datenbank.
• Vergeben Sie Rollen lokal und führen Sie auch den Nachweis dazu lokal.
• Betrachten Sie Gruppenangaben des Identitätsanbieters als Hinweis, nicht als Berechtigungssystem.

Schweiz: Was sich für Ihre Anbindung ändert

Beide Protokolle sind vollwertig unterstützt

Wenn Sie für die öffentliche Hand bauen oder an sie verkaufen, begegnen Ihnen die Identitätsdienste des Bundes. Die AGOV-Dokumentation zu cloud, SaaS and hyperscaler architectures hält fest, dass Zielanwendungen über OIDC oder SAML 2.0 an AGOV angebunden werden können, direkt oder über eine bestehende Identitäts- und Zugriffsverwaltung. Dieselbe Seite beschreibt die Unterstützung von OIDC mit dem Authorization-Code-Flow und PKCE. In diesem Umfeld lautet die Antwort auf «OAuth oder SAML» also oft: «Beides wird akzeptiert, nehmen Sie, was zu Ihrem Technologie-Stack und zum IAM-Team Ihrer Kundschaft passt.»

Behandeln Sie es nicht als beliebige OIDC- oder SAML-Anbindung

Einen Standard zu unterstützen heisst nicht, jede Umsetzung davon zu akzeptieren. Die Identitätsdienste des Bundes veröffentlichen eigene Profilanforderungen, Weiterleitungsverfahren und Attributzuordnungen. Lesen Sie die offizielle Integrationsspezifikation, bevor Sie etwas entwerfen, und planen Sie Zeit dafür ein. Teams, die diesen Schritt überspringen, entdecken Abweichungen meist spät, wenn Anpassungen nur noch mit Nacharbeit möglich sind.

Die Protokollwahl ist nicht die rechtliche Frage

Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) stellt klar, dass die Bearbeitung in der Cloud eine eigene Angelegenheit ist. In seinen cloud computing guidance erläutert der EDÖB, dass ein Cloud-Anbieter in der Regel als Auftragsbearbeiter für die Kundin nach Art. 9 des Datenschutzgesetzes handelt und die Kundin verantwortlich bleibt. Ein sicherer SSO-Ablauf ändert daran nichts.

Wenn Sie ein SaaS-Produkt mit den Identitäten Ihrer Nutzer:innen verbinden, fragen Sie in der Praxis:

• Welche Personendaten fliessen nach der Anmeldung zum Anbieter, und wo werden sie gespeichert?
• Braucht es eine Datenschutz-Folgenabschätzung? Das DSG sieht eine solche vor, wenn die Bearbeitung voraussichtlich ein hohes Risiko für die betroffene Person mit sich bringt; die Voraussetzungen prüfen Sie im text of the Act on Fedlex.
• Haben Sie einen Auftragsbearbeitungsvertrag mit dem Anbieter, und wissen Sie von Übermittlungen ins Ausland?

Diese Fragen gelten für SAML und OIDC gleichermassen. Sprechen Sie mit Ihrer Datenschutzberatung oder einer Anwältin, bevor Sie mit heiklen Daten live gehen, besonders wenn ein Anbieter in den USA sitzt.

Offene Standards statt proprietärer Anmeldung

Die öffentliche Hand und der Bildungsbereich in der Schweiz setzen zunehmend auf gemeinsame Identitäten wie AGOV oder SWITCH edu-ID. Für ein privates Produkt gilt dieselbe sinnvolle Lehre: Stützen Sie sich auf SAML und OIDC statt auf ein proprietäres Anmeldeverfahren. Offene Standards halten Ihnen den Wechsel des Identitätsanbieters offen, und sie stimmen die IT-Abteilungen Ihrer Kundschaft froh.

Typische Stolperfallen aus echten Projekten

• OAuth-Zugriffstokens als Anmeldenachweis verwenden. Wenn Sie Identität brauchen, prüfen Sie ein OIDC-ID-Token und kontrollieren Sie Aussteller, Zielgruppe, Signatur und Ablaufzeit.
• PKCE weglassen. Für öffentliche Clients wie SPAs und Mobile-Apps ist es ein günstiger Schutz, und der Authorization-Code-Flow mit PKCE gilt heute als Mindeststandard.
• Zu weit gefasste Berechtigungen. Fordern Sie an, was die Funktion jetzt braucht. Nutzer:innen und Sicherheitsprüfer:innen merken das beide.
• Schwache SAML-Prüfung. Prüfen Sie die Signaturen der Assertion, kontrollieren Sie Zielgruppenbeschränkungen und Zeitfenster und vertrauen Sie nie unsignierten Assertions. Nutzen Sie eine gepflegte Bibliothek statt eines selbst gebauten XML-Parsers.
• Veraltete Metadaten. SAML-Zertifikate laufen ab. Tragen Sie das Erneuerungsdatum in den Kalender ein oder überwachen Sie es besser automatisch.
• Kein Weg für den Austritt. Legen Sie fest, was mit Daten und Sitzungen einer Person geschieht, wenn der Identitätsanbieter meldet, dass sie weg ist.
• Authentifizierung mit Rollen vermischen. Oben behandelt, und eine Wiederholung wert, weil dieser Fehler am teuersten zu beheben ist.

Wenn Ihr Produkt mit anderen Systemen spricht

Die Anmeldung ist nur ein Teil des Bildes. Integrationen wie Postfächer, CRM-Systeme und Shops brauchen meist OAuth für delegierten Zugriff oder API-Tokens für Dienstkonten. Wie automatisierte Clients Tokens beziehen und sich selbst registrieren, zeigt diese Anleitung zu API tokens and self-registration for automated mailboxes. Welches System auch immer beteiligt ist: Bleiben Sie bei derselben Disziplin, also kurzlebige Tokens, enge Berechtigungen und eine klar zuständige Person pro Zugangsdatum.

Was das für ein Startup oder KMU in der Schweiz bedeutet

Kurz und mit klarer Haltung:

• Sie bauen ein neues Web- oder Mobile-Produkt? Starten Sie mit OIDC über eine seriöse Identitätsschicht.
• Sie verkaufen an grössere Unternehmen oder Behörden? Planen Sie zusätzlich SAML 2.0 ein und gestalten Sie Ihr Benutzermodell so, dass Identitätsanbieter, Person und Rolle getrennte Konzepte sind.
• Sie binden fremde APIs an? Nehmen Sie OAuth 2.0 mit PKCE und möglichst engen Berechtigungen.
• Sie bearbeiten Personendaten von Menschen in der Schweiz? Dokumentieren Sie, welche Daten wohin fliessen, und klären Sie die DSG-Fragen parallel zur technischen Arbeit, nicht danach.

Der Preis für einen Fehlentscheid ist selten ein spektakulärer Datenabfluss. Häufiger ist es eine Neuentwicklung, wenn die erste Unternehmenskundin SSO verlangt und Ihr Benutzermodell das nicht hergibt.

Wie Ampersand unterstützt

Wir sind ein kleines Zürcher Studio, und erfahrene Entwickler:innen bleiben vom ersten Gespräch bis zur Übergabe am Projekt. Das zählt gerade bei der Authentifizierung, wo frühe Entscheide zu Benutzermodellen und Integrationen teuer rückgängig zu machen sind. Wir bauen Websites, Webanwendungen und Plattformen, übernehmen Systemintegrationen und API-Anbindungen und bieten technische Beratung, Audits und CTO-Unterstützung auf Teilzeitbasis, geführt von erfahrenen Köpfen. Wenn Sie zwischen SAML, OIDC und OAuth für ein Produkt entscheiden oder eine bestehende Anmeldelösung prüfen lassen möchten, sehen Sie sich unsere Leistungen und Pakete an. Unser Guidance-Paket ist mit 799 CHF pro Monat ausgewiesen und Run & monitor mit 750 CHF pro Monat; weitere Angebote werden pro Projekt kalkuliert. Einen Eindruck davon, welche Systeme wir liefern, erhalten Sie auch in unseren Arbeiten.

Häufige Fragen

Was ist der wichtigste Unterschied zwischen OAuth und SAML?

OAuth 2.0 ist ein Autorisierungsrahmen: Er erlaubt einer Anwendung den Zugriff auf eine API mit begrenzten Rechten. SAML 2.0 ist ein Authentifizierungsstandard, der Nutzer:innen über einen Identitätsanbieter bei Anwendungen anmeldet. Die beiden überschneiden sich nur lose, und deshalb ist OIDC, das auf OAuth aufbaut, beim Login die passendere Entsprechung zu SAML.

Soll ich für eine neue Anwendung SAML oder OIDC nehmen?

Für die meisten neuen Produkte ist OIDC die einfachere Wahl, weil es für Web, Mobile und APIs gut funktioniert und auf JSON setzt. Ergänzen Sie SAML, wenn die IT-Umgebung einer Kundin es verlangt. Wenn Sie vor allem an grosse Organisationen verkaufen, planen Sie SAML von Anfang an ein.

Übernimmt OAuth die Authentifizierung?

Nicht von sich aus. Ein OAuth-Zugriffstoken sagt, dass eine Anwendung etwas tun darf, nicht, wer die Person ist. Für die Authentifizierung nehmen Sie OpenID Connect, das ein signiertes ID-Token ergänzt.

Unterstützen Schweizer Behördendienste beide Protokolle?

Ja. AGOV dokumentiert OIDC und SAML 2.0 als unterstützte Wege, um Anwendungen anzubinden. Der Dienst liefert Authentifizierung, aber keine Rollen oder Berechtigungen, also übernimmt Ihre Anwendung die Zugriffsverwaltung. Prüfen Sie die offizielle Integrationsspezifikation, bevor Sie entwickeln.

Wird meine Cloud-Lösung durch SSO DSG-konform?

Nein. Das Anmeldeprotokoll ist eine technische Wahl, während das DSG regelt, wie Personendaten bearbeitet werden und wer dafür verantwortlich ist. Die Cloud-Erläuterungen des Datenschutzbeauftragten halten fest, dass die Kundin verantwortlich bleibt, wenn ein Anbieter Daten für sie bearbeitet. Beurteilen Sie also das Risiko und schliessen Sie die passenden Verträge ab.

Quellen

• One practical comparison
• OAuth 2.1 draft
• cloud, SaaS and hyperscaler architectures
• AGOV
• cloud computing guidance
• text of the Act on Fedlex