SCIM vs SAML: Unterschiede und welches Sie brauchen

• Schnelle Antwort
• Was ist SCIM?
• Was ist SAML?
• SCIM vs SAML: direkter Vergleich
• Anwendungsfälle: Wann SCIM, SAML oder beides
• Welches sollten Sie zuerst implementieren?
• Wie Corma Sie bei der Einführung von SCIM und SAML unterstützt
• FAQ

Wenn Sie schon einmal 20 neue Mitarbeitende onboarden, Zugänge nach einem Offboarding entziehen oder einen einheitlichen Login über 40 SaaS-Tools durchsetzen mussten, sind Ihnen die Begriffe SCIM und SAML sicher schon begegnet. Beide stehen im Zentrum modernen Identity and Access Managements (IAM). Sie machen aber nicht dasselbe, und sie zu verwechseln führt zu echten Lücken bei Sicherheit, Compliance und operativer Effizienz.

Dieser Leitfaden erklärt genau, was jeder Standard tut, worin sie sich unterscheiden, und wie Sie entscheiden, welches Protokoll Ihre Organisation braucht, oder ob Sie beide einsetzen sollten.

Wenn Sie zunächst eine Übersicht in zwei Minuten bevorzugen, werfen Sie einen Blick auf unseren ergänzenden Artikel: SCIM und SAML in unter 5 Minuten erklärt.

Schnelle Antwort: SCIM vs SAML in einem Satz

SCIM (System for Cross-domain Identity Management) automatisiert, wie Benutzerkonten in Ihren SaaS-Anwendungen erstellt, aktualisiert und gelöscht werden. SAML (Security Assertion Markup Language) regelt, wie sich Benutzer authentifizieren: Es ist das Protokoll, das Single Sign-On (SSO) möglich macht.

Kurz gesagt: SCIM verwaltet, wer in einem System existiert. SAML verwaltet, wer sich anmelden darf. Sie lösen benachbarte Probleme und werden oft zusammen eingesetzt, decken aber jeweils eine andere Ebene Ihres Identity-Stacks ab.

Was ist SCIM?

SCIM (System for Cross-domain Identity Management) ist ein offener Standard, veröffentlicht in den RFCs 7642, 7643 und 7644, der einen einheitlichen Weg definiert, um Identitätsdaten zwischen Systemen auszutauschen. Seine Kernaufgabe ist das Provisioning: sicherzustellen, dass beim Eintritt, Rollenwechsel oder Austritt eines Benutzers seine Konten in allen verbundenen Anwendungen automatisch und sofort aktualisiert werden.

Wie SCIM funktioniert

SCIM basiert auf einem Client-Server-Modell über HTTPS und REST-APIs. Ihr Identity Provider (IdP), typischerweise Okta, Microsoft Entra ID (Azure AD) oder Google Workspace, fungiert als Quelle der Wahrheit für die Benutzeridentität. Wenn im IdP eine Änderung erfolgt (ein neuer Mitarbeiter wird angelegt, eine Rolle aktualisiert, ein Mitarbeiter verlässt das Unternehmen), gibt SCIM diese Änderung in Echtzeit an jeden verbundenen Service Provider weiter.

Ein typischer SCIM-Workflow für das Onboarding sieht so aus:

1. HR legt einen neuen Mitarbeiterdatensatz im HRIS an (z. B. BambooHR, HiBob).
2. Der IdP empfängt die neuen Benutzerdaten und löst ein SCIM-Provisioning-Ereignis aus.
3. SCIM sendet eine POST-Anfrage an jede verbundene SaaS-App (Slack, Notion, Salesforce usw.).
4. Jede App erstellt das Konto mit der richtigen Rolle und den richtigen Berechtigungen, ohne manuelle Eingriffe.

Dieselbe Logik gilt umgekehrt für das Deprovisioning: Wenn ein Mitarbeiter das Unternehmen verlässt, sendet SCIM innerhalb von Sekunden eine DELETE- oder Deaktivierungsanfrage an alle verbundenen Apps. Das ist sicherheitskritisch: Branchendaten zeigen, dass verwaiste Konten ehemaliger Mitarbeiter nach wie vor zu den Hauptursachen für unautorisierte SaaS-Zugriffe gehören.

Vertiefen Sie das Thema in unserem Leitfaden zum automatisierten User Provisioning und unserer detaillierten Übersicht zu den Best Practices für Provisioning im IAM.

Was SCIM NICHT tut

SCIM kümmert sich nicht um die Authentifizierung. Es verfügt über keinen Mechanismus, um zu prüfen, ob ein Benutzer beim Login wirklich der ist, für den er sich ausgibt. Es verwaltet ausschließlich die Existenz und die Attribute von Konten. Genau hier kommt SAML ins Spiel.

Was ist SAML?

SAML (Security Assertion Markup Language) ist ein offener, XML-basierter Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen zwei Parteien: einem Identity Provider (IdP) und einem Service Provider (SP). SAML 2.0 (die aktuelle Version, veröffentlicht 2005) ist das Rückgrat von Single Sign-On im Unternehmen. Es ist das, was Ihren Mitarbeitenden ermöglicht, in jedem SAML-fähigen SaaS-Tool auf "Mit Okta anmelden" (oder Google, oder Azure AD) zu klicken und Zugang zu erhalten, ohne ein weiteres Passwort einzugeben.

Wie SAML funktioniert

Wenn ein Benutzer auf einen Service Provider zugreifen möchte (z. B. Ihr Projektmanagement-Tool), leitet der SP ihn an den IdP weiter. Der IdP authentifiziert den Benutzer, indem er seine Identität über Anmeldedaten, MFA oder eine aktive Session prüft, und sendet dann ein digital signiertes XML-Dokument zurück, die sogenannte SAML-Assertion. Diese Assertion teilt dem SP mit: "Dieser Benutzer ist der, für den er sich ausgibt, und hier sind seine Attribute." Der SP vertraut der Assertion und gewährt entsprechend den Zugriff.

Der vollständige Ablauf:

1. Der Benutzer versucht, auf App X zuzugreifen (den Service Provider).
2. App X leitet den Benutzer mit einem SAML-AuthnRequest an den Identity Provider weiter.
3. Der IdP authentifiziert den Benutzer (Passwort + MFA, falls konfiguriert).
4. Der IdP erzeugt eine signierte SAML-Assertion und sendet sie an App X zurück.
5. App X validiert die Assertion und meldet den Benutzer ohne Passworteingabe an.

Was SAML NICHT tut

SAML legt keine Konten an. Ein Benutzer kann sich über SAML SSO nur dann erfolgreich authentifizieren, wenn sein Konto in der Zielanwendung bereits existiert. Wenn nicht, wird er auch mit einer gültigen SAML-Assertion blockiert. Genau diese Lücke schließt SCIM: Sie brauchen SCIM, um sicherzustellen, dass das Konto existiert, bevor SAML dagegen authentifizieren kann.

Für eine umfassendere Sicht auf das Zusammenspiel von SSO, SCIM und SAML lesen Sie unseren Artikel zu SSO, SCIM und SAML als Schlüsseltechnologien für automatisiertes Provisioning.

SCIM vs SAML: direkter Vergleich

Anwendungsfälle: Wann SCIM, SAML oder beides

Wann SCIM allein sinnvoll ist

Setzen Sie SCIM ein, wenn Ihr Hauptproblem die Verwaltung des Konto-Lebenszyklus ist. Wenn Ihr IT-Team Stunden mit dem manuellen Anlegen von Konten für neue Mitarbeitende verbringt oder Sie Audits scheitern, weil ehemalige Mitarbeitende noch aktive Zugriffe haben: SCIM ist das, was Sie zuerst brauchen.

Typische Szenarien, in denen SCIM einen sofortigen ROI liefert:

• Schnell wachsende KMU, in denen das HR-Onboarding täglich Provisioning-Rückstände erzeugt.
• Unternehmen, die mehrere IdPs einsetzen oder nicht-SSO-fähige Apps nutzen, die aber SCIM unterstützen.
• Organisationen, die eine ISO-27001- oder SOC-2-Zertifizierung anstreben, bei der automatisiertes Deprovisioning und Nachweise von Access Reviews verlangt werden. (Siehe: Wie SCIM und SAML bei der SOC-2- und ISO-27001-Compliance helfen)

Wann SAML allein sinnvoll ist

Setzen Sie SAML ein, wenn Ihr Hauptbedarf darin besteht, das Login-Erlebnis zu vereinfachen und abzusichern. Wenn Ihre Mitarbeitenden mit über 20 Passwörtern für SaaS-Tools jonglieren, wenn Phishing durch Passwort-Wiederverwendung ein reales Risiko ist oder wenn Sie MFA an einem zentralen Punkt durchsetzen wollen: SAML SSO ist Ihre Priorität.

Typische Szenarien:

• Unternehmen, die bereits ein sauberes Benutzerverzeichnis in Okta oder Azure AD aufgebaut haben und es auf SaaS-Apps ausweiten wollen.
• Organisationen, die die Helpdesk-Last durch Passwort-Reset-Anfragen reduzieren möchten.
• Teams mit kleiner, stabiler Belegschaft, bei denen Provisioning kein Engpass ist, Login-Friktion aber sehr wohl.

Wann Sie beides brauchen

In der Praxis brauchen die meisten Organisationen ab 50 Mitarbeitenden beides. SAML und SCIM sind per Design komplementär: SCIM stellt sicher, dass das Konto mit den richtigen Attributen existiert, SAML kümmert sich sicher um den täglichen Login. Zusammen liefern sie einen vollständigen Identity-Lebenszyklus: vom Provisioning am ersten Tag bis zum Deprovisioning am letzten, mit zentralisierter, passwortloser Authentifizierung dazwischen.

Diese Kombination schließt zudem eine kritische Sicherheitslücke: SAML allein widerruft nicht die Zugriffe auf alle Apps, wenn ein Mitarbeiter geht. Ein Benutzer kann seine IdP-Session verlieren, dabei aber weiter aktive Direktzugriffe auf Apps behalten, die keinen ausschließlichen SAML-Login erzwingen. SCIM stellt sicher, dass das Konto selbst gelöscht oder deaktiviert wird, nicht nur die Session.

Für Unternehmen, die mit Apps zu tun haben, die weder SCIM noch SAML unterstützen, lohnt sich ein Blick auf unsere Lösung für automatisiertes User Provisioning.

Welches sollten Sie zuerst implementieren? Ein Leitfaden nach Unternehmensgröße

Es gibt keine universelle Antwort darauf, ob man mit SCIM oder SAML beginnt: Es hängt von Ihrer Belegschaftsgröße, Ihrer Wachstumsrate, der Reife Ihres IdP und Ihren aktuellen Schmerzpunkten ab. Hier ein praktischer Rahmen.

Start-ups und frühphasige Unternehmen (1 bis 50 Mitarbeitende)

In dieser Phase ist Ihr SaaS-Stack wahrscheinlich klein, und Ihr IT-Team (sofern vorhanden) erledigt das Provisioning manuell. SAML SSO ist üblicherweise der wichtigste erste Schritt: Es zentralisiert die Authentifizierung, schafft Ordnung im Passwort-Chaos und legt das Fundament für den IdP, mit dem Sie skalieren werden. Die meisten modernen IdPs (Google Workspace, Okta) enthalten ein einfaches SCIM-Provisioning in ihren Standardplänen, sodass Sie beides mit minimalem Aufwand parallel aktivieren können.

Empfohlener Startpunkt: Einen IdP mit SSO einrichten und dann SCIM für Ihre 5 bis 10 meistgenutzten SaaS-Apps aktivieren.

Wachsende KMU (50 bis 500 Mitarbeitende)

Hier wird SCIM kritisch. Ab 50 Mitarbeitenden wird manuelles Provisioning zu einem echten operativen Engpass und einem Compliance-Risiko. Das Onboarding eines neuen Mitarbeitenden über mehr als 30 Apps manuell auszuführen, kostet einen ganzen IT-Arbeitstag. Ein Offboarding ohne SCIM bedeutet verwaiste Konten, die wochenlang aktiv bleiben. Priorisieren Sie die SCIM-Abdeckung über Ihren gesamten SaaS-Stack hinweg.

In dieser Phase haben Sie SAML SSO meist bereits etabliert. Das Ziel ist nun, den gesamten Lebenszyklus zu automatisieren: nicht nur den Login, sondern auch Anlage, Rollenänderungen und Löschung, sowie den Audit-Trail aufzubauen, den Sie für Compliance-Zertifizierungen brauchen.

Empfohlener Startpunkt: Alle SaaS-Apps kartieren, SCIM-fähige identifizieren und automatisiertes Provisioning umsetzen. Nutzen Sie eine Plattform wie die User-Provisioning-Lösung von Corma, um das über den gesamten Stack zu zentralisieren.

Mittelstand und Großunternehmen (500+ Mitarbeitende)

In dieser Größenordnung sind SCIM und SAML nicht verhandelbare Basis-Infrastruktur. Die Herausforderung verlagert sich von der Implementierung zur Governance: Abdeckung über Hunderte von Apps gewährleisten, rollenbasierten Zugriff auf Abteilungsebene steuern, Least-Privilege-Richtlinien durchsetzen und Access-Review-Berichte für Auditoren erzeugen.

Großunternehmen müssen außerdem mit Apps umgehen, die SCIM oder SAML nicht nativ unterstützen, was Workarounds wie browserbasierte Provisioning-Agenten oder API-Integrationen erfordert. Die User-Provisioning- und Access-Management-Funktionen einer dedizierten IAM-Plattform sind in dieser Größenordnung unverzichtbar.

Empfohlener Startpunkt: Aktuelle SCIM-/SAML-Abdeckungslücken auditieren, Hochrisiko-Apps ohne automatisiertes Deprovisioning priorisieren und eine strukturierte Identity Governance inklusive Access Reviews einführen.

Wie Corma Sie bei der Einführung von SCIM und SAML unterstützt

SCIM und SAML einzeln pro SaaS-App zu implementieren ist zeitaufwendig, fehleranfällig und schwer zu auditieren. Corma ist eine SaaS-Management- und IAM-Plattform für IT-Teams und CIOs, die volle Sichtbarkeit und Kontrolle über ihren Anwendungszugriff brauchen, ohne von Grund auf eine komplexe Identity-Infrastruktur aufbauen zu müssen.

Was Corma konkret übernimmt:

• Automatisiertes Provisioning und Deprovisioning via SCIM: Corma verbindet sich mit Ihrem IdP und propagiert Lebenszyklus-Ereignisse automatisch über Ihren gesamten SaaS-Stack, einschließlich Apps, die SCIM nicht nativ unterstützen, mithilfe von Browser-Agenten, wo nötig.
• SAML-SSO-Abdeckung: Corma integriert sich in Ihren bestehenden IdP (Okta, Azure AD, Google), erweitert die SSO-Abdeckung und deckt Apps auf, die noch direkte Logins nutzen, ein häufiges Shadow-IT- und Compliance-Risiko.
• Access Reviews und Identity Governance: Corma erzeugt automatisierte Access-Review-Workflows, die direkt auf die Kontrollanforderungen von ISO 27001 und SOC 2 abgestimmt sind. Siehe die Corma-Lösung für automatisierte Access Reviews.
• Vollständige SaaS-Sichtbarkeit: Corma erkennt alle von Ihren Mitarbeitenden genutzten Apps, auch außerhalb Ihres SCIM-/SAML-Perimeters, und gibt Ihrem IT-Team ein vollständiges Bild des Zugriffsrisikos.
• Für IT-Teams gebaut: Corma ist für IT-Teams konzipiert, die SaaS-Zugriffe steuern, nicht für Enterprise-Identity-Engineers, die monatelang komplexe Pipelines konfigurieren wollen.

Ob Sie gerade erst mit SCIM und SAML starten oder eine bestehende Implementierung auditieren: Corma liefert die operative Schicht, um das ohne Tabellenkalkulationen oder manuelles Ticketing zu steuern.

→ Demo anfragen, um zu sehen, wie Corma SCIM-Provisioning und SAML-Abdeckung über Ihren SaaS-Stack hinweg automatisiert

Häufige Fragen zu SCIM vs SAML

Ist SCIM besser als SAML?

SCIM und SAML sind keine konkurrierenden Standards: Sie lösen unterschiedliche Probleme und sind dafür gedacht, zusammenzuarbeiten. SCIM verwaltet das User Provisioning (wer ein Konto besitzt und welche Zugriffe hat). SAML übernimmt die Authentifizierung (wie Benutzer beim Login ihre Identität nachweisen). "Besser" ist die falsche Frage: In einem ausgereiften IAM-Setup brauchen Sie beides.

Kann man SAML ohne SCIM nutzen?

Ja, und viele Organisationen tun das, vor allem in der Frühphase. Mit SAML SSO allein können sich Benutzer mit einer einzigen Identität anmelden, aber Konten müssen weiterhin manuell in jeder Anwendung angelegt und gelöscht werden. Daraus entsteht eine Lücke: Wenn ein Mitarbeitender geht, wird seine SAML-Session widerrufen, seine Konten können aber in jedem SaaS-Tool weiterbestehen, bis jemand sie manuell entfernt. SCIM schließt diese Lücke, indem es das Deprovisioning automatisiert.

Kann man SCIM ohne SAML nutzen?

Ja. SCIM kann unabhängig von SAML laufen. Manche Organisationen führen SCIM-Provisioning über ihren IdP ein, während sich die Benutzer weiterhin mit direkten Anmeldedaten pro Anwendung einloggen. Das ist üblich, wenn ein Unternehmen SSO noch nicht ausgerollt hat. Sie erhalten die Vorteile der Lebenszyklus-Automatisierung von SCIM (keine verwaisten Konten, automatisiertes Onboarding) ohne die SSO-Schicht. SAML lässt sich später leicht ergänzen, wenn SCIM bereits steht.

Was ist der Unterschied zwischen SCIM und SAML beim SSO?

SAML ist das Protokoll, das SSO ermöglicht: Es erlaubt Ihrem IdP, Benutzer über mehrere Anwendungen hinweg zu authentifizieren, ohne separate Passwörter zu verlangen. SCIM ist kein SSO-Protokoll. Es ist ein Provisioning-Protokoll, das Benutzerkonten zwischen Ihrem IdP und Ihren Anwendungen synchron hält. SSO und automatisiertes Provisioning sind komplementäre Funktionen, keine Alternativen.

Nutzt Okta SCIM oder SAML?

Okta nutzt beides. Als Identity Provider kann Okta als SAML-IdP agieren, um SSO über SAML-fähige Anwendungen bereitzustellen, und als SCIM-Client, um Provisioning-Ereignisse an SCIM-fähige SaaS-Apps zu senden. Die meisten Enterprise-Okta-Deployments setzen beide Protokolle gemeinsam ein.

Ist SCIM vs SAML für die ISO-27001-Compliance relevant?

Ja, beide sind direkt relevant. Die Annex-A-Kontrollen der ISO 27001:2022 zum Access Management (A.5.15 bis A.5.18) verlangen, dass Zugriffe kontrolliert und zeitnah gewährt, geändert und entzogen werden. SCIM automatisiert die Provisioning-/Deprovisioning-Seite dieser Anforderung. SAML (über SSO) unterstützt die Kontrollanforderungen für Authentifizierung. Beide gemeinsam zu implementieren, mit ordnungsgemäßer Audit-Protokollierung, gehört zu den effektivsten Wegen, den Access-Management-Teil eines ISO-27001-Audits zu erfüllen. Siehe unseren detaillierten Leitfaden zu ISO 27001 und IAM: vollständiger Implementierungsleitfaden.

Welche Apps unterstützen SCIM und SAML?

Die meisten großen Enterprise-SaaS-Anwendungen unterstützen beides: Salesforce, Slack, Notion, GitHub, Google Workspace, Microsoft 365, Zoom, Atlassian, Workday, ServiceNow und Hunderte weitere. SCIM-Unterstützung ist typischerweise in Business- oder Enterprise-Plänen verfügbar. Das bedeutet, dass eine wesentliche Funktion von SCIM hinter einer Paywall liegt, bekannt als SCIM Scheme. Kleinere oder spezialisierte Apps unterstützen oft SAML SSO, aber kein SCIM, was alternative Provisioning-Ansätze erfordert. Entdecken Sie unsere Identity-Governance-Lösung, um diese Fälle zu steuern.

Welche Alternative habe ich, wenn meine Apps kein SCIM unterstützen?

Ein IAM-Tool wie Corma ist eine Alternative, die hilft, Zugriffsanfragen zu verwalten, Benutzer zu provisionieren und zu deprovisionieren und Least Privilege effizient durchzusetzen, ohne ausschließlich auf SCIM-APIs angewiesen zu sein.