SCIM und SSO für Marketing-Tools: Was die Enterprise-IT wirklich verlangt

Die SSO/SCIM-Anforderung kommt auf eine von zwei Arten zustande. Manchmal ist sie in einen Sicherheitsfragebogen eingebettet: „Unterstützt Ihre Anwendung Single Sign-On per SAML 2.0 oder OIDC? Unterstützt sie automatisiertes Provisioning per SCIM 2.0?" Manchmal kommt sie als direkte Anweisung der IT: Jeder Anbieter, der personenbezogene Daten verarbeitet, muss sich über den unternehmensweiten IdP authentifizieren. Kein eigenständiger Passwort-Login, keine geteilten Zugangsdaten, keine Ausnahmen.

So oder so ist die Konsequenz dieselbe. Entweder integriert sich Ihr Marketing-Tool in den Identity Provider des Unternehmens, oder es wird ersetzt.

Marketing-Tools - URL-Shortener, Kampagnen-Tracker, UTM-Manager - landen jetzt in diesem Review-Prozess, weil Marketing-Teams in der Click-Event-Schicht personenbezogene Daten verarbeiten. Ein Short Link, der die IP-Adresse, den User-Agent und den Referrer einer Person protokolliert, verarbeitet personenbezogene Daten. Diese Verarbeitung gehört in das durch den IdP gesteuerte Zugriffsmodell.

Dieser Beitrag ist die Procurement-Checklisten-Version: Was SSO und SCIM voraussetzen, wo Marketing-SaaS zu kurz greift, und die fünf Fragen, die Sie ins Discovery-Gespräch mit dem Anbieter mitnehmen sollten.

TL;DR#

• SAML 2.0 und OIDC bedienen unterschiedliche IdP-Generationen - Legacy-Enterprise läuft auf SAML; moderne IdPs sprechen nativ OIDC. Ein Anbieter, der nur eines unterstützt, deckt nur die Hälfte des Marktes ab.
• SCIM 2.0 ist die Provisioning-Schicht: Es erstellt Konten, aktualisiert sie und - entscheidend - deprovisioniert sie. JIT-Provisioning erstellt Konten beim ersten Login, deprovisioniert sie aber nicht. Für Audit-Zwecke ist SCIM die Anforderung.
• Die meisten Marketing-Tools verstecken SSO hinter einem Enterprise-Tier, das 500–2.000 USD/Monat über dem Basisplan kostet. Anbieter, die SSO ohne diesen Aufschlag auf einem Business-Tier inkludieren, sind die Ausnahme.
• Die entscheidenden Procurement-Fragen: SAML-Metadaten-URL, SCIM-Endpunkt-URL, Rotationsintervall des Bearer Tokens, Deprovisioning-Latenz und Mapping von IdP-Gruppen zu Rollen.

SAML 2.0 und OIDC: Warum es beides noch gibt#

SAML 2.0, 2005 von OASIS veröffentlicht, ist ein XML-basierter Federation-Standard. Der IdP sendet eine signierte SAML Response an die Assertion Consumer Service URL des SP; der SP validiert die Signatur anhand des IdP-Zertifikats, extrahiert das Subject und die Attribute Statements und erstellt eine Session.

OIDC, aufgebaut auf OAuth 2.0, erledigt dieselbe Aufgabe mit JSON. Der IdP stellt ein JWT (das ID Token) aus, das der SP gegen den JWKS-Endpunkt des IdP verifiziert.

Beide existieren parallel, weil Legacy-Enterprise-IdPs - On-Premises AD FS, ältere Okta-Konfigurationen, Ping Federate - primär auf SAML setzen. Cloud-native IdPs wie Google Workspace und der moderne Stack von JumpCloud sprechen nativ OIDC und tragen SAML als sekundäres Protokoll mit. Gemischte Unternehmen betreiben beides.

SP-initiierter vs. IdP-initiierter Flow. SP-initiierter Login ist der Standard: Nutzer ruft die App auf, App leitet zum IdP weiter, IdP authentifiziert und sendet die Antwort zurück. IdP-initiiert überspringt die SP-Weiterleitung - der Nutzer klickt auf eine Kachel im Okta- oder Entra-Dashboard und der IdP schickt eine unaufgeforderte Assertion direkt an den SP. Beide Flows müssen funktionieren. IdP-initiiert ist schwieriger sicher zu implementieren (CSRF-ähnliches Injection-Risiko, wenn der SP die Binding- und Destination-Attribute nicht validiert), und Anbieter, die nur SP-initiiert unterstützen, scheitern, wenn die IT versucht, die App-Kachel im Unternehmens-Dashboard hinzuzufügen.

SCIM 2.0: Die Provisioning-Schicht#

SCIM 2.0 - RFC 7644 - automatisiert das Lifecycle-Management von Nutzerkonten über SaaS-Anwendungen hinweg. Drei Kernoperationen:

Provisionierung: POST /Users mit den Attributen des Nutzers. Der SP erstellt das Konto und gibt die neue ID zurück.

Updates: PATCH /Users/:id mit einem JSON-Patch-Payload - Display Name, Abteilung, Rolle, was auch immer der IdP autoritativ verwaltet.

Deprovisionierung: DELETE /Users/:id (Hard Delete) oder PATCH /Users/:id mit { "active": false } (Soft Deactivate, das gängigere Enterprise-Muster).

Deprovisioning ist der audit-kritische Teil. Verwaiste Konten - Konten ehemaliger Mitarbeitender, die nie gekündigt wurden, weil die IT es vergessen hat oder weil der Anbieter automatisiertes Deprovisioning nicht unterstützt - sind eine konsistente Angriffsfläche. ISO 27001 Control A.9.2 und SOC 2 CC6.2 verlangen beide einen dokumentierten Prozess zur Entziehung von Zugriffsrechten. Manuelle Deprovisionierung scheitert vorhersehbar: Das Offboarding-Ticket wird übersehen, das Konto bleibt aktiv. SCIM macht die Deprovisionierung automatisch und auditierbar - der IdP feuert die Deactivate-Anfrage, der SP loggt sie, und dieses Log ist das Audit-Artefakt.

Die Marketing-Tool-Lücke#

Die meisten Enterprise-SaaS-Kategorien - HR, CRM, ITSM, Code-Hosting - liefern SSO in Tarifen aus, die ein Mid-Market-Team tatsächlich kaufen kann. Marketing-Tools sind langsamer gewesen. Das Muster, das ich konsistent sehe: SSO ist als „Enterprise"-Feature gelistet, in einem separaten Tier, der 500–2.000 USD/Monat über dem Business-Plan kostet. Die Implikation: SSO sei ein Luxus-Upsell für große Organisationen, nicht eine grundlegende Sicherheitskontrolle.

Diese Rahmung ist zunehmend unvereinbar damit, wie Enterprise-IT Anbieter bewertet. Wenn ein Marketing-Tool Click-Daten zu identifizierbaren Nutzern verarbeitet, fällt es unabhängig von der Kategorie in den Geltungsbereich des Access-Governance-Programms des Unternehmens. SSO hinter einem Premium-Tier zu verstecken bedeutet, dass das Marketing-Team das Tool außerhalb des IdP betreibt - genau das Ergebnis, das die IT vermeiden will.

Anbieter, die SSO im Business-Tier ohne separaten Aufschlag inkludieren, sind die Ausnahme. Unter den URL-Shortenern: Elido inkludiert SAML/OIDC-SSO und SCIM-Provisioning im Business-Plan über WorkOS. Bl.ink inkludiert SSO im Team-Plan. Loops (E-Mail-Automatisierung) und Customer.io liefern SSO beide im Business-Tier ohne separates Enterprise-Gate aus.

Wenn ein Anbieter SSO nur unter „Contact sales for Enterprise pricing" listet, schauen Sie auf einen manuellen Deprovisioning-Workflow für jeden Mitarbeiterwechsel - solange dieses Tool im Stack bleibt.

IdP-Landschaft und Kompatibilität#

Sechs IdPs dominieren die Enterprise-IT:

Okta ist der häufigste Cloud-IdP in US-Unternehmen. Okta liefert SAML 2.0, OIDC und ein ausgereiftes SCIM-Interface. Ein Anbieter, der im Okta Integration Network mit bestätigtem SCIM gelistet ist, bedeutet, dass die Konfiguration des IT-Teams dokumentiert und getestet ist; ansonsten schreibt das Team eine eigene Integration.

Microsoft Entra ID (früher Azure AD) ist der Standard in Microsoft-365-Umgebungen. Sein SCIM-Provisioning-Agent fragt den Anwendungsendpunkt per Polling ab - das Standard-Intervall liegt bei 40 Minuten, Deprovisioning ist also nicht sofortig. Im Procurement-Review erwähnenswert.

JumpCloud unterstützt SAML 2.0, OIDC und SCIM 2.0. Beliebt bei Mid-Market-Teams, die ein Cloud-Directory ohne On-Premises-AD wollen.

Google Workspace nutzt OIDC nativ; SAML 2.0 steht für Kompatibilität mit Legacy-Anwendungen zur Verfügung. Drittanbieter-SCIM-Integrationen folgen dem Standard-Pfad nach RFC 7644.

OneLogin pflegt SAML 2.0, OIDC und SCIM. Verbreitet in Mid-Market-Organisationen, die sich vor der Marktkonsolidierung durch Okta standardisiert haben.

WorkOS ist eine Anbieter-seitige Plattform (kein End-User-IdP), die SaaS-Anwendungen zur Umsetzung von SSO und SCIM nutzen. Ein Anbieter, der „wir nutzen WorkOS" sagt, drückt Kompatibilität mit Okta, Entra, JumpCloud, Google und OneLogin gleichzeitig aus. Elidos SSO-Integration ist auf WorkOS aufgebaut. Die praktische Implikation für die IT: Wenn Sie Okta oder Entra auf einen SCIM-Endpunkt zeigen können, funktioniert die Integration ohne anbieterspezifische Konfigurationsarbeit.

JIT-Provisioning vs. SCIM-Provisioning#

Just-in-Time-Provisioning erstellt ein Nutzerkonto beim ersten SSO-Login. Kein Pre-Provisioning-Schritt ist erforderlich; Attribute kommen aus der SAML-Assertion oder dem OIDC-Token.

JIT löst die Provisionierungs-Hälfte sauber. Die Deprovisionierungs-Hälfte ist das Problem. Wenn der Nutzer aus dem IdP entfernt wird, funktioniert seine SSO-Session nicht mehr - aber das Konto in der SaaS-Anwendung bleibt bestehen. Langlebige API-Tokens können weiter funktionieren. Das Konto erscheint in jedem Audit aktiver Nutzer.

Für ISO-27001- oder SOC-2-Umgebungen ist JIT allein unzureichend. Die Audit-Frage lautet nicht „Kann sich dieser Mitarbeiter einloggen?", sondern „Gibt es einen prüfbaren Nachweis, dass der Zugriff entzogen wurde?". JIT erzeugt diesen Nachweis nicht. SCIM tut es: Das DELETE- oder { "active": false }-Event wird sowohl beim IdP als auch beim SP geloggt, mit Zeitstempel versehen und ist abfragbar.

Wenn Ihr Anbieter-Review Deprovisioning-Nachweise erfordert, fragen Sie explizit, ob SCIM-2.0-Deprovisioning unterstützt wird. Ein Anbieter, der „ja, wir unterstützen SSO" antwortet, wenn die Frage nach SCIM war, beantwortet eine andere Frage.

Rollen-Mapping: IdP-Gruppe zu SaaS-Rolle#

Das Standardmuster: Der IdP hat zwei Gruppen - marketing-team (alle Mitarbeitenden) und marketing-leads (Team-Leads). Die SaaS-Anwendung hat zwei Rollen: Marketer und Admin. Das IT-Team konfiguriert das Mapping einmal: marketing-team → Marketer, marketing-leads → Admin. Wenn jemand zwischen Gruppen wechselt, aktualisiert der nächste SCIM-Sync die Rolle automatisch.

SCIM transportiert die Gruppenmitgliedschaft über die Groups-Ressource (GET /Groups, POST /Groups, PATCH /Groups/:id). Nicht alle SCIM-Implementierungen unterstützen Gruppen-Sync - einige Anbieter implementieren nur User-Provisioning, was bedeutet, dass Rollen-Mapping weiterhin pro Nutzer manuell konfiguriert werden muss. Fragen Sie den Anbieter explizit, ob SCIM Group Push unterstützt wird und ob das Rollen-Mapping vom Admin konfigurierbar ist, ohne dass ein Support-Ticket nötig wird.

Für EU-basierte Organisationen können die IdP-Gruppenmitgliedschaftsdaten, die über SCIM fließen, selbst personenbezogene Daten gemäß Art. 4(1) DSGVO darstellen. Der Beitrag EU-Datenresidenz für Marketing beschreibt, was Ihr AVV zur Identitätsdaten-Schicht sagen sollte. Ihr SaaS-Anbieter ist ein Auftragsverarbeiter für diese Daten, und der AVV sollte das explizit adressieren.

Was im Procurement zu fragen ist#

Fünf Fragen, die darüber entscheiden, ob die SSO/SCIM-Integration eines Marketing-Tools ein halber Tag IT-Konfiguration oder ein mehrwöchiges Projekt ist:

SAML-Metadaten-URL. Kann der Anbieter eine statische URL liefern, die auf seine SP-Metadaten zeigt (Entity ID, ACS URL, Signing Certificate)? Genau das fügen Sie in Okta oder Entra ein. Manuelle Metadaten-Eingabe pro Kunde ist ein Warnsignal.

SCIM-Endpunkt und Auth-Methode. Wie lautet die SCIM-Basis-URL? Bearer Token ist der Standard; OAuth-2.0-Client-Credentials sind komplexer. Wie ist das Rotationsintervall des Tokens? Ein statisches Token, das niemals rotiert wird, ist eine Sicherheitslücke.

Deprovisioning-Latenz. Wenn der IdP PATCH /Users/:id { "active": false } oder DELETE sendet, wie schnell wird der Zugriff entzogen? Das Provisioning-Intervall von Entra liegt seitens des IdP standardmäßig bei 40 Minuten. Der Anbieter sollte sich auf ein Verarbeitungsfenster festlegen, sobald die Anfrage eintrifft. Die Kombination beider Latenzen ist das, was Ihr SOC-2-Auditor abfragen wird.

Group-Push-Unterstützung. SCIM Group Push ist getrennt von SCIM User Provisioning. Wenn der Anbieter nur User-Sync implementiert, ist Rollen-Mapping eine manuelle Pro-Nutzer-Konfiguration. Fragen Sie explizit nach.

IdP-Tile-Unterstützung. Kann die Anwendung als Kachel im Okta- oder Entra-Dashboard hinzugefügt werden und IdP-initiierten Login unterstützen?

Die Compliance-Ebene#

ISO 27001 Annex A Control A.9.2 verlangt, dass Nutzerzugriffsrechte gemäß einem dokumentierten Prozess gewährt, überprüft und entzogen werden. A.9.3 verlangt, dass sich Nutzer nur mit ihnen zugewiesenen Credentials authentifizieren. SCIM ist der operative Mechanismus, der „HR-Offboarding" mit „SaaS-Zugriff widerrufen" verbindet - ohne manuelle Schritte.

SOC 2 CC6.2 verlangt, dass Organisationen Nutzer registrieren und autorisieren, bevor Zugriff gewährt wird. CC6.3 verlangt regelmäßige Zugriffsüberprüfung und -entziehung. Das SCIM-Deprovisioning-Log - ein mit Zeitstempel versehener Datensatz darüber, wann der IdP der SaaS-Anwendung die Anweisung gab, einen Nutzer zu deaktivieren oder zu löschen - ist das Audit-Artefakt, das CC6.3-Compliance für jede in Scope befindliche Anwendung nachweist.

Elido ist ISO-27001-zertifiziert. SOC 2 Type II ist in Arbeit, Ziel ist H2 2026. Die Identitäts-Posture - SAML/OIDC über WorkOS, SCIM-2.0-Deprovisioning, gruppenbasiertes Rollen-Mapping - ist auf der Trust-Seite und im Brief solutions/enterprise dokumentiert. BAAs sind im Business-Plan für HIPAA-nahe Workflows verfügbar.

Der DSGVO-für-URL-Shortener-Cornerstone behandelt Art. 28 und Art. 32 vollständig. SSO und SCIM sind die technischen Kontrollen aus Art. 32 - Authentifizierung über SSO, Deprovisioning über SCIM - keine eigenständigen Features. Sie sind Komponenten der Sicherheits-Posture, die Ihr Datenschutzbeauftragter im Rahmen des Art.-32-Reviews bewertet.

/pricing zeigt die Plan-Aufstellung und wo SSO/SCIM auftauchen. /solutions/compliance ist die Zusammenfassung für das Einkaufsteam. Das Gespräch über Deprovisioning-Nachweise gehört in denselben Procurement-Call wie der AVV, die Sub-Auftragsverarbeiter-Liste und die Data-Residency-Zusage - das sind die Fragen, die darüber entscheiden, ob ein Marketing-Tool das Security-Review besteht.

NIST SP 800-63-3 Digital Identity Guidelines, abgerufen am 12.05.2026, ist das autoritative Rahmenwerk für Assurance Levels und Authenticator Types, das vielen Enterprise-IdP-Richtlinienanforderungen zugrunde liegt. Der Federation-Abschnitt - 800-63C - ist direkt relevant für die Konfiguration der SAML- und OIDC-Integration.