Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich habe seit 2023 drei B2B-SaaS-Produkte ausgeliefert – zwei mit über 50.000 $ MRR, eines mit über 500.000 $ MRR – und die Nachfrage nach SSO + RBAC + Audit-Logs für RFPs kommt bei jedem spätestens im sechsten Monat. Dieser Beitrag ist die 8-Punkte-Checkliste, die den Realitäts-Check übersteht, die drei Fehlermodi, die mich um 2 Uhr nachts wecken, und die Originalspezifikationen, aus denen jeder Punkt stammt. „Out of the box“ bedeutet produktionsreif, nicht „in einem Tutorial zusammengebaut“ – der Unterschied beträgt ca. 600 Entwicklerstunden pro Element, wenn Sie den Boilerplate überspringen.

Verifizierte Quellen: SAML 2.0 Specifications (OASIS) · SCIM 2.0 Protocol (RFC 7644) · Better Auth SSO Plugin · OWASP Logging Cheat Sheet · GDPR Article 17 (Right to Erasure) · SOC 2 Trust Services Criteria · NIST 800-63B Digital Identity Guidelines · Stripe Billing API · OWASP Access Control Cheat Sheet

Zuletzt aktualisiert: 16. Mai 2026 · Changelog

Zusammenfassung: Ein B2B-SaaS-Starter-Kit, das „SSO + RBAC + Audit-Logs out of the box“ verspricht, bedeutet acht produktionsreife Anforderungen, nicht nur drei Kontrollkästchen: (1) SAML 2.0 SP-initiierte SSO mit IdP-initiierter Fallback-Lösung, (2) SCIM 2.0 Benutzer-Provisionierung mit Deprovisioning, (3) RBAC mit Vererbung für Org > Workspace > Rolle, (4) Audit-Log-Trail mit Aufbewahrung + DSGVO-Pseudonymisierung, (5) Session-Audit mit IP + User-Agent, (6) Durchsetzung einer IP-Allowlist, (7) MFA via TOTP oder WebAuthn, (8) Abrechnung pro Nutzer ("Per-Seat") mit SSO-Reconciliation. Drei „Out-of-the-box“-Behauptungen, die nichts bedeuten: SAML nur mit Signierung (kein IdP-initiiert), SCIM ohne Deprovisioning, Audit-Logs mit 30-Tage-Aufbewahrung. TanStack Ship liefert alle acht; die meisten Kits von 2026 liefern drei.

B2B SaaS Starter 2026: Ein Realitäts-Check für SSO, RBAC und Audit-Logs

Was „Out of the box“ eigentlich bedeutet

„Out of the box“ in einem B2B-Starter-Kontext bedeutet produktionsreif bis zur ersten Woche der Evaluierung durch den Käufer – nicht „scaffolded“, nicht „funktioniert in der Entwicklungsumgebung“, nicht „wir haben ein TODO im SCIM-Handler hinterlassen“. Damit ein Kit glaubwürdig behaupten kann, SSO + RBAC + Audit-Logs out of the box zu liefern, muss es acht spezifische Anforderungen erfüllen. Die meisten 2026er Kits erfüllen drei.

Seit 2023 habe ich drei B2B-SaaS-Produkte auf Basis von Cloudflare Workers + Better Auth + D1 veröffentlicht – zwei mit über 50.000 $ MRR, eines mit über 500.000 $ MRR. Die Anforderungen (RFP) nach SSO + RBAC + Audit-Logs kommen bei jedem spätestens im sechsten Monat. Dieser Beitrag ist die Checkliste, die den Käuferanrufen und der technischen Kalkulation standhält.

Der 8-Punkte Realitäts-Check

1. SAML 2.0 SP-initiierte SSO + IdP-initiierter Fallback (94 Stunden)

Der Käufer hat Okta, Entra ID, Google Workspace oder JumpCloud und möchte einen Single-Click-Login über das IdP-Dashboard. Die 94 Stunden setzen sich zusammen aus: 28 Stunden für den SP-initiierten Ablauf (Ihre App generiert einen AuthnRequest, der IdP sendet eine signierte Assertion zurück), 22 Stunden für den IdP-initiierten Ablauf (unaufgeforderte Assertion, kein vorheriger AuthnRequest), 18 Stunden für die Validierung von Signatur + Assertion gemäß der SAML 2.0 Spezifikation, 26 Stunden für Just-in-Time-Provisionierung mit Rollen-Mapping.

Die Falle: Signierte Assertion vs. signierte Response. Viele IdPs signieren nur die Assertion; einige signieren nur die Response; einige verlassen sich auf TLS. Validieren Sie BEIDES gemäß Spezifikation. In TanStack Ship verarbeitet das Better Auth SSO Plugin beide Abläufe. Aus 94 Stunden werden somit 4 Stunden für die IdP-Metadatenkonfiguration.

2. SCIM 2.0 Benutzer-Provisionierung + Deprovisioning (78 Stunden)

SCIM ermöglicht es dem IdP, Ereignisse im Benutzer-Lebenszyklus (Erstellen, Aktualisieren, Deaktivieren) ohne manuelle Arbeit von Administratoren zu übertragen. Die 78 Stunden: 32 Stunden für die RFC 7644 Endpunkte /Users und /Groups, 24 Stunden für den Deprovisioning-Handler (muss aktive Sitzungen innerhalb von 60 Sekunden widerrufen), 22 Stunden für das Group-to-Role-Mapping.

Die Falle: Verzögerung bei der Deprovisionierung. Der IdP sendet DELETE; mein Handler hat den Benutzerdatensatz widerrufen, aber 30 aktive Sitzungen in Cloudflare KV aktiv gelassen. Die Benutzer blieben 6 Stunden lang eingeloggt. Die Lösung ist eine pro-Sitzung Widerrufsliste, die bei jeder Anfrage überprüft wird, ODER ein Sitzungsversionszähler, der beim Deprovisioning-Ereignis inkrementiert wird.

3. RBAC mit Vererbung für Org > Workspace > Rolle (88 Stunden)

RBAC für B2B ist nicht flach. Ein Nutzer ist „Owner“ auf Org-Ebene, „Admin“ in Workspace A, „Member“ in Workspace B. Der Rollenvererbungs-Bug tritt auf, wenn der Code prüft: „Ist dieser Nutzer irgendwo ein Admin?“ und daraufhin übergreifende Workspace-Rechte einräumt. Die 88 Stunden: 28 Stunden für die Org-Role-Tabelle, 32 Stunden für die Workspace-Role-Tabelle mit ausdrücklichem Verbot von Abfragen über Workspaces hinweg, 28 Stunden für die Policy-Enforcement-Schicht. Eine produktionsreife B2B-RBAC-Policy mit Org-Vererbung:

// app/lib/rbac/org-policy.ts
import { createAccessControl } from "better-auth/plugins/access"
import { defaultStatements, adminAc } from "better-auth/plugins/admin/access"

const statement = {
  ...defaultStatements,
  org: ["settings:read", "settings:write", "billing:read", "billing:write",
        "members:read", "members:invite", "members:remove", "audit:read"],
  workspace: ["create", "read", "update", "delete", "members:invite"],
  sso: ["config:read", "config:write", "metadata:read"],
  audit: ["read", "export"],
} as const

export const ac = createAccessControl(statement)

export const owner = ac.newRole({
  ...adminAc.statements,
  org: ["settings:read", "settings:write", "billing:read", "billing:write",
        "members:read", "members:invite", "members:remove", "audit:read"],
  workspace: ["create", "read", "update", "delete", "members:invite"],
  sso: ["config:read", "config:write", "metadata:read"],
  audit: ["read", "export"],
})

export const admin = ac.newRole({
  org: ["settings:read", "members:read", "members:invite", "audit:read"],
  workspace: ["create", "read", "update", "members:invite"],
  sso: ["config:read", "metadata:read"],
  audit: ["read"],
})

export const member = ac.newRole({
  org: ["settings:read"],
  workspace: ["read"],
})

export const billing_admin = ac.newRole({
  org: ["settings:read", "billing:read", "billing:write"],
})

export const auditor = ac.newRole({
  org: ["settings:read", "audit:read", "audit:export"],
  workspace: ["read"],
})

Die Rollen auditor und billing_admin sind wichtig für die SOC2-Bereitschaft – Käufer möchten ihrem internen Auditteam Lesezugriff gewähren, ohne sie zu vollständigen Administratoren zu machen.

Ein SAML SP-initiierter SSO-Handler in TanStack Ship:

// app/routes/api/sso/saml/callback.ts
import { sso } from "~/lib/auth"
import type { APIRoute } from "astro"

export const POST: APIRoute = async ({ request, locals }) => {
  const formData = await request.formData()
  const samlResponse = formData.get("SAMLResponse") as string
  const orgSlug = formData.get("RelayState") as string

  // Signatur auf Response UND Assertion gemäß SAML 2.0 Spezifikation validieren
  const result = await sso.verifySAMLResponse(samlResponse, {
    validateResponseSignature: true,
    validateAssertionSignature: true,
    wantAssertionsSigned: true,
    audience: env.SAML_SP_ENTITY_ID,
    recipient: `${env.APP_URL}/api/sso/saml/callback`,
  })

  if (!result.valid) {
    return new Response("Invalid SAML response", { status: 401 })
  }

  // JIT Provisionierung: Nutzer beim ersten Login erstellen
  const user = await sso.provisionUser({
    email: result.attributes.email,
    orgSlug,
    role: result.attributes.role ?? "member",
  })

  return sso.createSessionResponse(user, locals)
}

4. Audit-Log-Trail mit Aufbewahrung + DSGVO-Pseudonymisierung (96 Stunden)

Audit-Logs sind „wer was wann von wo aus gemacht hat, mit Vorher/Nachher-Differenz“. Compliance-Teams fragen am ersten Tag eines Enterprise-Verkaufs danach; zudem sind Logs der größte einzelne Kostenfaktor für Speicherplatz in einem mehrjährigen Deployment. Das OWASP Logging Cheat Sheet ist hierbei die Spezifikation.

Die 96 Stunden: 36 Stunden für den Schreibpfad (Audit-Event mit Actor, Target, Action, Vorher/Nachher-Zustand, IP, User-Agent, Org-ID, Workspace-ID), 28 Stunden für den Lesepfad (Audit-Log-UI mit Filtern), 32 Stunden für die Aufbewahrung + Pseudonymisierung gemäß Art. 17 DSGVO.

Die Falle: Konflikt zwischen Aufbewahrung und DSGVO. Ein Nutzer bittet um die Löschung seiner Daten; das Audit-Log enthält eine Zeile mit seiner E-Mail. Eine naive Implementierung löscht den Nutzerdatensatz, aber lässt die Audit-Zeile stehen, die auf einen nicht existierenden Nutzer verweist. Die Lösung besteht in der Pseudonymisierung bei Löschung: Die Zeile beibehalten, die E-Mail durch einen salted Hash ersetzen und den Actor als deleted-user-{hash} markieren. Dies erfüllt die Anforderungen der DSGVO UND hält den Audit-Trail intakt. Aus den 96 Stunden werden hierdurch 4 Stunden für Änderungen an der Aufbewahrungskonfiguration.

5. Session-Audit mit IP + User-Agent (44 Stunden)

Jedes Sitzungsereignis (Login, Logout, MFA-Challenge, Passwortänderung, Rollenwechsel) löst ein Audit-Event aus, das mit IP und User-Agent markiert ist. Käufer fragen: „Zeigen Sie mir jede IP, die sich in den letzten 90 Tagen als dieser Benutzer angemeldet hat.“ Die 44 Stunden: 24 Stunden für den Session-Event Emit-Hook (Better Auth abonniert Lifecycle-Events), 12 Stunden für IP-Geolocation (MaxMind GeoLite2), 8 Stunden für die Erkennung verdächtiger Sitzungen (zwei Länder in 5 Minuten → Warnung).

6. Durchsetzung einer IP-Allowlist (38 Stunden)

Die meisten B2B-Käufer ab 100.000 $ ARR verlangen ein IP-Allowlisting für Admin-Operationen. Die Falle: CDN-Egress-IPs. Der Traffic des Käufers kommt über die Edge-IPs von Cloudflare, nicht über dessen eigene Unternehmens-IPs. Wenn Sie die Unternehmens-IPs auf die Allowlist setzen, blockieren Sie alles. Die Lösung ist, die cf-connecting-ip (die wahre, von Cloudflare weitergeleitete Client-IP) zu überprüfen, nicht die unmittelbare Verbindungs-IP. Die Cloudflare-Dokumentation für CF-Connecting-IP behandelt die Spezifikation.

7. MFA via TOTP oder WebAuthn (52 Stunden)

MFA ist im Enterprise-Bereich nicht verhandelbar. Käufer verlangen TOTP (RFC 6238, OWASP MFA Cheat Sheet) oder WebAuthn-Plattform-Authentifikatoren (NIST 800-63B AAL2+). Nur E-Mail basierte MFA wird abgelehnt; SMS-MFA wird auf Grund von SIM-Swap-Risiken gemäß NIST ebenfalls abgelehnt.

8. Abrechnung pro Nutzer ("Per-Seat") mit SSO-Reconciliation (62 Stunden)

Der Käufer bezahlt pro Nutzer (Per-Seat); die Anzahl der Nutzer ist die Vereinigung von SCIM-provisionierten und manuell eingeladenen Nutzern. Die Abstimmung (Reconciliation) läuft allnächtlich – SCIM deprovisioniert 5 Benutzer, die Sitzplatzanzahl sinkt um 5, die nächste Rechnung spiegelt die geringere Anzahl wider. Die Falle: Das SCIM-Deprovisioning verringert die Anzahl an Sitzen, aber Stripe hat den Monat bereits in Rechnung gestellt. Die Reconciliation markiert die Änderung mit Wirksamkeit für den nächsten Zyklus und schreibt den ungenutzten Teilbetrag gut. Hierbei gilt der Stripe Webhook Idempotency Guide.

Die 8-Punkte-Matrix, bewertet im Vergleich zur Starter-Kit-Landschaft 2026

Die Symbole ✅ / ⚠️ / ❌ spiegeln die Produktionsreife in Woche 1 wider. Makerkit liefert gutes RBAC und SAML, aber rudimentäre Audit-Logs. ShipFast liefert ein flaches RBAC und nur TOTP – SAML und SCIM sind Community-Plugins. Wasp / Open-SaaS liefert nichts von diesen acht Elementen. Next-Forge bietet nur flaches RBAC und TOTP an.

Die Kalkulation von 552 Stunden

Die "From scratch" Zahlen beinhalten die sieben genannten Fallen sowie die notwendige Integrationsarbeit (RBAC ↔ Audit-Logs ↔ SCIM ↔ SSO). Die 24 Stunden für TanStack Ship gehen davon aus, dass das Team die Produktoberfläche ausgewählt hat und nur ihren IdP sowie Stripe Price IDs konfigurieren muss.

Wo das „Out of the box“-Versprechen zerbröckelt

Drei „Out-of-the-box“-Behauptungen auf Landingpages für Starter-Kits aus 2026, die absolut nichts bedeuten:

1. „SAML SSO inklusive“ – aber nur SP-initiiert. Der Käufer, der auf die Okta-Kachel klickt, erhält einen 403-Fehler, da Ihr Handler unaufgeforderte Assertions ablehnt.
2. „SCIM Provisionierung“ – aber nur für den Erstelldialog. SCIM DELETE wird ignoriert; der Benutzer ist 6 Stunden später weiterhin aktiv. Ein SOC2-Fehlschlag.
3. „Audit-Logs aktiviert“ – aber mit 30-tägiger Aufbewahrung. Die Anforderung für SOC2 ist 1 Jahr, für HIPAA 6 Jahre. Mit lediglich 30 Tagen fällt man bei jedem Fragebogen durch.

Wenn Ihr Kit einen dieser drei Punkte erfüllt, ist es lediglich „scaffolded und wartet darauf, dass die Lücken mit 200 Arbeitsstunden geschlossen werden“.

FAQ

F: Wie lange dauert es, mit TanStack Ship ein B2B-SaaS mit allen 8 Anforderungen auszuliefern?

A: 3–4 Tage für die IdP-Metadatenkonfiguration + Stripe-Setup + 1–2 Wochen für das UI.

F: Kann ich SCIM ignorieren, falls mein Käufer nicht danach fragt?

A: Ja, aber rechnen Sie mit der Frage im nächsten RFP. SCIM ist nach SSO die zweithäufigste Anfrage. Wenn Sie dies jetzt weglassen, werden Sie es später unter Zeitdruck einfügen müssen. Unser Deep Dive zu SSO + RBAC geht näher darauf ein, wieso das Ignorieren der beiden der häufigste Fehler ist.

F: Beinhaltet TanStack Ship einen SAML IdP oder lediglich die SP-Seite?

A: Lediglich die SP-Seite. Ihr Käufer bringt seinen eigenen IdP mit (Okta, Entra ID, Google Workspace).

F: Wie sieht der Vergleich mit Clerk, Auth0 oder WorkOS aus?

A: Dabei handelt es sich um Managed Auth Services, keine Boilerplates. Clerk und Auth0 berechnen ihre Kosten pro MAU (Monthly Active User); WorkOS berechnet pro B2B-Verbindung. TanStack Ship wird mit einer Einmallizenz erworben; die Auth-Oberfläche gehört Ihnen und Sie zahlen lediglich die Edge-Gebühren von Cloudflare.

F: Was ist mit HIPAA, PCI-DSS, FedRAMP?

A: Liegen bezüglich der oben genannten acht Elemente außerhalb des Geltungsbereichs (Out of scope). Zertifizierungen erfordern jeweils ein Compliance-Audit (mehr als 200 Stunden, 8–12 Wochen für SOC2 Type II). Aufbewahrungsskripte sind vorverkabelt (standardmäßig 1 Jahr); das Audit selbst ist ein Steuerprüfungsmandat (CPA Engagement).

Liefern Sie die 8 B2B-Anforderungen in 24 statt 552 Stunden. Erfahren Sie hier mehr über die Auth + SSO + SCIM Module von TanStack Ship → oder vergleichen Sie diese mit anderen SaaS-Boilerplates.