Authentifizierung in Next.js: Optionen im Vergleich
Next.js-Authentifizierung: Auth.js vs Better Auth vs Clerk | We.Inc
Auth.js, Better Auth, Clerk, Supabase Auth und eine selbst gebaute Session für Next.js 16 im Vergleich, mit Setup-Code für jede Option und einer Auswahlhilfe, die die Liste auf deine Anforderungen eingrenzt.
Authentifizierung in Next.js: Optionen im Vergleich
Für die meisten Next.js-Apps nimmst du besser eine Bibliothek, statt Auth selbst zu schreiben. Clerk ist gehostet und am schnellsten eingerichtet, Supabase Auth passt zu Apps, die schon auf Supabase laufen, und Better Auth oder Auth.js halten die Nutzer in deiner eigenen Datenbank. Egal wofür du dich entscheidest: Prüfe die Session im Servercode noch einmal, denn Prüfungen im Proxy allein schützen keine Daten.
Auf einen Blick
Option
Wo Nutzer gespeichert sind
Clerk
Server von Clerk
@clerk/nextjs, ClerkProvider, clerkMiddleware in proxy.ts
Supabase Auth
Dein Supabase-Projekt
@supabase/ssr-Clients plus ein Proxy, der die Session erneuert
Better Auth
Deine eigene Datenbank
auth-Instanz plus app/api/auth/[...all]/route.ts
Auth.js (next-auth v5 beta)
Deine Datenbank oder ein JWT-Cookie
auth.ts plus app/api/auth/[...nextauth]/route.ts
Selbst bauen
Deine eigene Datenbank
jose oder iron-session, httpOnly-Cookies, eine Datenzugriffsschicht
Der offizielle Next.js-Guide listet zwölf kompatible Auth-Bibliotheken auf, mehr Auswahl, als die meisten wollen. Dieser Vergleich grenzt das auf die fünf Wege ein, die die meisten Teams tatsächlich abwägen, zeigt für jeden den minimalen Code im App Router und erklärt die Prüfungen, die du deiner App schuldest, egal welche Bibliothek die Anmeldung übernimmt.
Hake die Anforderungen an, die dir wichtig sind, etwa Nutzerdaten in der eigenen Datenbank oder fertige Anmeldeseiten.
Die Auswahlhilfe blendet Optionen aus, die nicht jede angehakte Anforderung erfüllen.
Öffne den Setup-Code der übrigen Optionen und vergleiche, wie viel du schreiben müsstest.
Lies vor dem Release den Sicherheitsabschnitt, egal welche Option du wählst.
Speichere Sessions in Cookies, die auf dem Server mit HttpOnly, Secure, SameSite und einem Ablaufdatum gesetzt werden, wie es der Next.js-Guide empfiehlt.
Leg eine verifySession()-Funktion in eine einzige server-only-Datei und ruf sie aus Pages, Server Actions und Route Handlers auf.
Verlass dich bei Auth-Prüfungen nicht auf ein Layout. Layouts werden bei clientseitiger Navigation nicht neu gerendert, die Prüfung kann also übersprungen werden.
Halte den Session-Payload klein: eine Nutzer-ID und eine Rolle, niemals eine E-Mail-Adresse oder Telefonnummer.
Erzeuge Secrets mit openssl rand -base64 32 (oder npx auth secret bei Auth.js) und bewahre sie in Umgebungsvariablen auf.
Häufige Fragen
Wird NextAuth noch gepflegt?
Auth.js, das Projekt, das früher NextAuth hieß, schreibt auf seiner eigenen Website, dass es jetzt Teil von Better Auth ist. Der Installationsbefehl für Next.js lautet weiterhin npm install next-auth@beta. Neue Projekte starten oft direkt mit Better Auth, während bestehende Auth.js-Apps weiter funktionieren.
Kann ich Seiten allein mit proxy.ts schützen?
Nein. Die Next.js-Dokumentation nennt Prüfungen im Proxy optimistisch: gut für schnelle Weiterleitungen auf Basis eines Cookies, aber keine Sicherheitsgrenze. Prüfe die Session noch einmal nah an den Daten, denn Server Functions und Routen außerhalb des Matchers laufen nie durch den Proxy.
Welche Option ist am günstigsten?
Bibliotheken, die Nutzer in deiner eigenen Datenbank speichern, wie Better Auth oder Auth.js, haben keine Gebühr pro Nutzer; du zahlst für deine Datenbank und den E-Mail-Versand. Supabase Auth enthält im kostenlosen Plan 50,000 monatlich aktive Nutzer, Stand Oktober 2026. Das aktuelle kostenlose Kontingent von Clerk findest du auf dessen Preisseite.
Funktionieren diese Optionen mit Next.js 16?
Ja. Clerk und Supabase dokumentieren beide proxy.ts für Next.js 16 und middleware.ts für ältere Versionen, und Better Auth bietet einen Cookie-Helper für den Proxy plus eine vollständige Session-Prüfung für Servercode.
Zustandslose Sessions oder Datenbank-Sessions?
Ein signiertes Cookie (zustandslos) ist einfacher und braucht keine Abfrage, lässt sich aber vor seinem Ablauf nicht widerrufen. Eine Datenbank-Session kostet eine Abfrage pro Prüfung und erlaubt es Nutzern, sich auf allen Geräten abzumelden. Viele Bibliotheken lassen dir die Wahl.
Gehostet oder selbst betrieben
Clerk übernimmt für dich die Nutzerverwaltung, die Anmeldeseiten und das Session-Handling, und du setzt seine Komponenten in dein Layout. Du tauschst etwas Kontrolle und bei wachsender Größe eine monatliche Rechnung gegen Tempo und eine ausgereifte Oberfläche ab dem ersten Tag.
Better Auth und Auth.js laufen in deiner App und schreiben in deine Datenbank. Dir gehören die Daten und die Seiten, und du bist auch für E-Mail-Zustellung, Passwort-Reset-Abläufe und Upgrades zuständig.
Wenn du Supabase schon nutzt
Supabase Auth verknüpft die Anmeldung direkt mit der Row Level Security von Postgres, sodass eine Policy wie auth.uid() = user_id die Daten auf Datenbankebene schützt. Das Paket @supabase/ssr speichert die Session in Cookies, damit Server Components sie lesen können.
Die Supabase-Dokumentation warnt, dass getSession() ungeprüfte Daten zurückgibt. Nutze getClaims(), das die Token-Signatur prüft, oder getUser(), das beim Auth-Server nachfragt, bevor du der Identität des Nutzers vertraust.
Selbst schreiben
Der Next.js-Guide führt dich mit einer Server Action für das Formular, Zod für die Validierung, bcrypt fürs Hashing und jose zum Signieren eines Session-Cookies mit sieben Tagen Laufzeit durch. Das ist eine gute Methode, die einzelnen Bausteine kennenzulernen.
Für den Produktivbetrieb empfiehlt derselbe Guide eine Bibliothek, denn Rate Limiting, E-Mail-Verifizierung, Kontoverknüpfung und Mehrfaktor-Anmeldung summieren sich schnell.
Minimales Setup für jede Option
Clerk
Installiere @clerk/nextjs und setze NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY und CLERK_SECRET_KEY. Unter Next.js 16 heißt die Middleware-Datei proxy.ts.
Supabase Auth
Ein Server-Client, der pro Anfrage aus dem Cookie-Store mit dem Publishable Key erstellt wird. getClaims() prüft das Token, bevor du ihm vertraust.
Better Auth
Häng den Handler an eine Catch-all-Route und lies die Session dann auf dem Server mit den Request-Headern.