Clerk vs Auth.js v5 in 2026: Die Entscheidung, die deine Auth-Roadmap bestimmt
Wenn du ein B2B-SaaS auf Next.js 15 startest oder neu aufsetzt, taucht die Frage Clerk vs Auth.js 2026 im ersten Architekturmeeting auf und geht nicht mehr weg. Beide Optionen sind vertretbar. Beide lassen sich aber auch leicht aus den falschen Gründen wählen: Clerk, weil die Demo so mühelos aussah, Auth.js, weil es kostenlos ist. Dieser Beitrag ist ein fokussierter Direktvergleich entlang der acht Entscheidungspunkte, die tatsächlich bestimmen, mit welcher Wahl du in zwei Jahren noch zufrieden bist.
Vier Auth-Optionen haben wir breiter in unserem Vergleich der Next.js-Authentifizierungs-Frameworks gegenübergestellt. Hier gehen wir tiefer auf die beiden ein, die die meisten Teams auf die Shortlist setzen.
Clerk vs Auth.js in 2026: Die Kurzfassung
Clerk ist eine gemanagte Authentifizierungsplattform. Du installierst ein SDK, packst deine App in einen Provider und bekommst Sign-up, Sign-in, Organisationen, Rollen, SSO und ausgereifte UI-Komponenten als Service. Auth.js v5 (früher NextAuth) ist eine Open-Source-Bibliothek. Dir gehören die Konfiguration, die Datenbank, das Session-Modell und jedes Feature, das du über den reinen Login hinaus brauchst.
Diese Einordnung erzählt schon den Großteil der Geschichte: Clerk verkauft dir Zeit, Auth.js verkauft dir Kontrolle. Die acht Punkte unten zeigen, was deine Situation tatsächlich verlangt.
1. Setup-Zeit für Multi-Tenant-Organisationen
Clerk liefert Organisationen als First-Class-Primitive. Orgs anlegen, Mitglieder einladen, Rollen zuweisen und zwischen Workspaces wechseln ist alles eingebaut, inklusive UI. Ein funktionierendes Multi-Tenant-Skelett ist eine Tagesaufgabe, und der Großteil dieses Tages fließt in dein eigenes Datenbankmodell, nicht in Clerk.
Auth.js v5 kennt kein Konzept einer Organisation. Du modellierst Tenants, Mitgliedschaften und Rollen in deinem eigenen Schema, schreibst den Einladungsflow, baust den Org-Switcher und erzwingst die Mandantentrennung in Middleware oder Server Actions. Für ein erfahrenes Team sind das ein bis zwei Wochen Arbeit, bevor die Edge Cases anfangen. Das ist keine verlorene Zeit, wenn du ohnehin ein individuelles Tenancy-Modell brauchst, aber es ist reales Budget.
2. Eingebaute UI-Komponenten
Clerks vorgefertigte Komponenten (SignIn, UserProfile, OrganizationSwitcher) sind Produktionsqualität und für die meisten Marken ausreichend themebar. Der Trade-off zeigt sich, sobald dein Designsystem von dem abweicht, was die Theming-API erlaubt. Ab dem Punkt baust du die UI auf Clerks Headless-Hooks neu, und ein Teil der Zeitersparnis verpufft.
Auth.js gibt dir gar keine UI. Jedes Formular, jeder Fehlerzustand und jedes E-Mail-Template gehört dir. Langsamer am Anfang, aber es gibt keine Customization-Decke und keinen Kampf mit der Komponentenbibliothek von jemand anderem.
3. DSGVO und Datenresidenz
Diesen Punkt unterschätzen europäische Teams am häufigsten. Clerk speichert Nutzerdaten auf eigener Infrastruktur, und standardmäßig hieß das bisher US-Hosting. Wenn deine Enterprise-Kunden EU-Datenresidenz verlangen oder deine AVV-Zusagen Übermittlungen personenbezogener Daten außerhalb der EU einschränken, musst du prüfen, was Clerk zum Zeitpunkt der Vertragsunterschrift vertraglich garantieren kann, nicht was ein Changelog andeutet. Für manche Beschaffungsprozesse ist ein US-basierter Subprozessor im Authentifizierungspfad ein K.-o.-Kriterium, egal wie die Papierlage aussieht.
Auth.js hält jeden Nutzerdatensatz und jede Session in deiner eigenen Datenbank. Deine Daten liegen dort, wo dein Postgres liegt, was für die meisten unserer Kunden Frankfurt oder eine andere EU-Region bedeutet. Es gibt keinen zusätzlichen Subprozessor, den du offenlegen musst, kein Transfer Impact Assessment für die Auth-Schicht und eine Zeile weniger in jedem Sicherheitsfragebogen. Wenn du an deutsche Enterprises oder regulierte Branchen verkaufst, kann dieser eine Punkt den Vergleich entscheiden.
4. Preise bei 1k, 10k und 100k MAU
Clerks Free Tier deckt grob die ersten 10.000 monatlich aktiven Nutzer ab, danach zahlst du pro MAU in einem Bezahlplan, wobei Features wie SAML SSO und erweitertes Organisations-Tooling hinter höheren Stufen oder Add-ons liegen. Bei 1k MAU zahlst du wahrscheinlich nichts. Bei 10k bist du am Rand des Free Tiers. Bei 100k MAU wird die Pro-Nutzer-Bepreisung zu einem echten Posten von mehreren Tausend Euro pro Monat, und Finance wird fragen, warum. Prüfe immer die aktuelle Preisseite; die Struktur hat sich mehr als einmal verschoben.
Auth.js ist freie Software. Ihre Kosten sind Engineering-Zeit: der initiale Bau von Orgs, RBAC und Flows plus laufende Wartung. Diese Kosten fallen vorne an und sind weitgehend fix, während Clerks Kosten mit deinem Erfolg skalieren. Produkte mit niedrigem Preis und hohem Volumen spüren das am härtesten, weil die Auth-Ausgaben linear wachsen, während der Umsatz pro Nutzer klein bleibt.
5. Enterprise SSO und SAML-Aufwand
Mit Clerk ist SAML SSO für einen Enterprise-Kunden Konfiguration, kein Engineering. Den Okta- oder Entra-ID-Tenant eines Kunden anzubinden ist eine Aufgabe von Minuten bis Stunden, und SCIM-Provisioning ist auf der Plattform verfügbar. Wenn ein Mid-Market-Deal an der Frage "Unterstützt ihr SSO?" hängt, schließt diese Geschwindigkeit Deals ab.
Mit Auth.js musst du SAML und SCIM selbst bauen oder von einem spezialisierten Broker zukaufen, den du selbst integrierst. Rechne mit einem mehrwöchigen Aufwand, wenn du es richtig machen willst, inklusive Metadaten-Austausch, Zertifikatsrotation und einer Konfigurations-UI pro Kunde. Teams, die diese Planung überspringen, versprechen SSO im Sales-Call und entdecken den echten Umfang erst danach.
6. Passkeys und WebAuthn in 2026
Beide unterstützen Passkeys, mit unterschiedlich viel Reibung. Clerk bietet Passkey-Login als Plattform-Feature, das du einschaltest, die UI ist abgedeckt. In Auth.js v5 existiert WebAuthn-Support, hängt aber von deinem Adapter ab und verlangt, dass du die Enrollment- und Verwaltungs-Experience selbst baust. Es funktioniert, und Self-Hosting-Enthusiasten haben es produktiv im Einsatz, aber plane Tage statt Minuten ein.
7. Der Migrationspfad, wenn du aus deiner Wahl herauswächst
Die Migration weg von Auth.js ist vergleichsweise überschaubar: Deine Nutzer, gegebenenfalls Passwort-Hashes und Sessions liegen bereits in deiner Datenbank, der Wechsel zu einer anderen Bibliothek oder einer gemanagten Plattform ist ein Importproblem.
Die Migration weg von Clerk ist härter. Der Export von Nutzerdaten wird unterstützt, aber Passwort-Hashes, MFA-Registrierungen und Organisationsstrukturen brauchen sorgfältiges Mapping in das, was danach kommt, und aktive Sessions überleben nicht. Plane einen erzwungenen Re-Login und eine Welle an Support-Tickets ein. Nichts davon ist ein Grund, Clerk zu meiden, aber ein Grund, die Wahl als langfristig statt leicht umkehrbar zu behandeln.
8. Wenn Clerks Nutzermodell mit komplexer Multi-Tenancy kollidiert
Clerk geht davon aus, dass ein Nutzer zu Organisationen gehört, mit Rollen pro Organisation. Viele B2B-Produkte passen in diese Form. Manche nicht: Marktplätze, auf denen ein Account für mehrere juristische Personen handelt, hierarchische Tenants mit vererbten Berechtigungen, Grants auf Ressourcenebene quer über Org-Grenzen oder Agenturen, die Kunden-Workspaces mit delegiertem Zugriff verwalten.
In diesen Fällen pflegst du am Ende dein eigenes Autorisierungsmodell parallel zu dem von Clerk, synchronisierst Mitgliedschaftsdaten zwischen beiden und debuggst Drift. Wenn deine Berechtigungsmatrix schon wie ein Forschungspapier aussieht, wird Clerks Org-Primitive zu etwas, um das du herumarbeitest, statt darauf zu bauen. Auth.js, das nie vorgab, deine Domäne zu modellieren, passt paradoxerweise besser, weil das gesamte Modell von Tag eins an dir gehört.
Entscheidungstabelle
| Entscheidungspunkt | Clerk | Auth.js v5 |
|---|---|---|
| Multi-Tenant-Setup-Zeit | Etwa ein Tag | Ein bis zwei Wochen |
| UI-Komponenten | Enthalten, themebar | Selbst bauen |
| DSGVO-Datenresidenz | Vertraglich prüfen; standardmäßig US-basiert | Deine Datenbank, deine Region |
| Kosten bei 100k MAU | Mehrere Tausend pro Monat | Infrastruktur plus Wartung |
| SAML-SSO-Aufwand | Minuten bis Stunden | Mehrwöchiger Bau oder Broker |
| Passkeys | Einschalten | Adapterabhängiger Bau |
| Migration weg | Schmerzhaft, erzwungener Re-Login | Überschaubar, die Daten gehören dir |
| Komplexe Tenancy-Modelle | Kämpft gegen dein Domänenmodell | Vollständig deins |
Unsere Empfehlung
Wähle Clerk, wenn Speed-to-Market dominiert, dein Tenancy-Modell konventionell ist, Enterprise SSO auf der kurzfristigen Sales-Roadmap steht und deine Kunden keine harten EU-Residenzanforderungen an die Auth-Schicht stellen. Ein Seed-Stage-B2B-SaaS, das an den US- und UK-Mid-Market verkauft, passt gut in dieses Profil.
Wähle Auth.js v5, wenn du in die EU mit strengen Datenresidenz-Erwartungen verkaufst, dein MAU-Volumen im Verhältnis zum Umsatz pro Nutzer hoch ist oder dein Berechtigungsmodell komplex genug ist, dass eine gehostete Org-Primitive gegen dich arbeiten würde. Akzeptiere die zwei Wochen Tenancy-Arbeit als Preis dafür, dass dir deine Roadmap gehört.
Wenn du unsicher bist, welches Profil du bist, ist das selbst ein Signal, bewusst zu entscheiden. Auth-Entscheidungen härten schnell aus: Jedes Feature, das du shippst, referenziert das Session-Modell, und ein späterer Austausch berührt alles. Genau diese Art von Entscheidung arbeiten wir in unseren Tech-Stack-Strategie-Engagements durch, und wenn die Antwort Auth.js plus eine individuelle Tenancy-Schicht lautet, baut unser Team dieses Fundament im Rahmen von Custom-Software-Development-Projekten auf Next.js und Symfony.
Du wägst diese Entscheidung gerade für dein eigenes Produkt ab? Schick uns eine kurze Beschreibung deines Tenancy-Modells und deiner Compliance-Anforderungen an hello@wolf-tech.io oder besuche uns auf wolf-tech.io. Ein halbstündiges Gespräch jetzt ist billiger als eine Migration später.
FAQ
Ist Auth.js v5 in 2026 produktionsreif? Ja. Der v5-Rewrite ist für den Praxiseinsatz stabil, mit einem ausgereiften Adapter-Ökosystem für gängige ORMs und Datenbanken. Die Vorsicht gilt nicht der Stabilität, sondern dem Umfang: Alles jenseits des Logins baust du selbst.
Kann ich mit Clerk starten und später zu Auth.js wechseln? Technisch ja, praktisch teuer. Der Nutzerexport funktioniert, aber Sessions, MFA-Registrierungen und Org-Strukturen brauchen ein Remapping, und deine Nutzer werden ausgeloggt. Behandle die initiale Wahl als langfristiges Commitment.
Funktioniert Clerk mit einem Symfony- oder separaten API-Backend? Ja. Clerk stellt JWTs aus, die dein Backend verifizieren kann. Dasselbe gilt für Auth.js. In hybriden Architekturen aus Next.js plus Symfony entscheiden die acht Punkte oben, nicht die Backend-Kompatibilität.