Uwierzytelnianie w Next.js: Auth.js vs Better Auth vs Clerk | We.Inc
Porównanie Auth.js, Better Auth, Clerk, Supabase Auth i własnej sesji dla Next.js 16, z kodem konfiguracji dla każdej opcji i selektorem, który zawęża listę do Twoich potrzeb.
Uwierzytelnianie w Next.js: porównanie opcji
W większości aplikacji Next.js wybierz bibliotekę zamiast pisać uwierzytelnianie samodzielnie. Clerk jest hostowany i najszybszy w konfiguracji, Supabase Auth pasuje do aplikacji, które już korzystają z Supabase, a Better Auth lub Auth.js trzymają użytkowników w Twojej własnej bazie danych. Cokolwiek wybierzesz, sprawdzaj sesję ponownie w kodzie serwerowym, bo same kontrole w proxy nie chronią danych.
W skrócie
Opcja
Gdzie przechowywani są użytkownicy
Clerk
Serwery Clerk
@clerk/nextjs, ClerkProvider, clerkMiddleware w proxy.ts
Supabase Auth
Twój projekt Supabase
Klienty @supabase/ssr plus proxy odświeżające sesję
Better Auth
Twoja własna baza danych
Instancja auth plus app/api/auth/[...all]/route.ts
Auth.js (next-auth v5 beta)
Twoja baza danych lub ciasteczko JWT
auth.ts plus app/api/auth/[...nextauth]/route.ts
Własne rozwiązanie
Twoja własna baza danych
jose lub iron-session, ciasteczka httpOnly, warstwa dostępu do danych
Oficjalny przewodnik Next.js wymienia dwanaście zgodnych bibliotek uwierzytelniania, czyli więcej wyboru, niż większość osób potrzebuje. To porównanie zawęża go do pięciu dróg, które zespoły naprawdę rozważają, pokazuje minimalny kod każdej z nich w App Router i wyjaśnia kontrole, które musisz zapewnić aplikacji niezależnie od tego, która biblioteka loguje użytkowników.
Zaznacz wymagania, które są dla Ciebie ważne, na przykład przechowywanie danych użytkowników we własnej bazie lub gotowe ekrany logowania.
Selektor ukrywa opcje, które nie spełniają każdego zaznaczonego wymagania.
Otwórz kod konfiguracji pozostałych opcji i porównaj, ile musiałbyś napisać.
Przed wdrożeniem przeczytaj sekcję o bezpieczeństwie, niezależnie od wybranej opcji.
Przechowuj sesje w ciasteczkach ustawianych na serwerze z HttpOnly, Secure, SameSite i datą wygaśnięcia, jak zaleca przewodnik Next.js.
Umieść funkcję verifySession() w jednym pliku tylko serwerowym i wywołuj ją ze stron, Server Actions i Route Handlers.
Nie polegaj na layoucie przy kontrolach uwierzytelniania. Layouty nie renderują się ponownie przy nawigacji po stronie klienta, więc kontrola może zostać pominięta.
Trzymaj zawartość sesji małą: identyfikator użytkownika i rolę, nigdy adres e-mail ani numer telefonu.
Generuj sekrety poleceniem openssl rand -base64 32 (lub npx auth secret dla Auth.js) i trzymaj je w zmiennych środowiskowych.
Najczęściej zadawane pytania
Czy NextAuth jest nadal rozwijany?
Auth.js, projekt dawniej nazywany NextAuth, podaje na swojej stronie, że jest teraz częścią Better Auth. Jego polecenie instalacji dla Next.js to nadal npm install next-auth@beta. Nowe projekty często zaczynają bezpośrednio od Better Auth, a istniejące aplikacje na Auth.js nadal działają.
Czy mogę chronić strony wyłącznie za pomocą proxy.ts?
Nie. Dokumentacja Next.js nazywa kontrole w proxy optymistycznymi: dobre do szybkich przekierowań na podstawie ciasteczka, ale niebędące granicą bezpieczeństwa. Weryfikuj sesję ponownie blisko danych, bo Server Functions i trasy spoza matchera nigdy nie przechodzą przez proxy.
Która opcja jest najtańsza?
Biblioteki przechowujące użytkowników w Twojej własnej bazie danych, takie jak Better Auth czy Auth.js, nie mają opłaty za użytkownika: płacisz za bazę danych i wysyłkę e-maili. Supabase Auth obejmuje 50,000 aktywnych użytkowników miesięcznie w darmowym planie według stanu na październik 2026. Aktualny darmowy limit Clerk sprawdź na jego stronie z cennikiem.
Czy te opcje działają z Next.js 16?
Tak. Clerk i Supabase dokumentują proxy.ts dla Next.js 16 oraz middleware.ts dla starszych wersji, a Better Auth zapewnia pomocnika do ciasteczek dla proxy oraz pełną kontrolę sesji dla kodu serwerowego.
Sesje bezstanowe czy w bazie danych?
Podpisane ciasteczko (bezstanowe) jest prostsze i nie wymaga odczytu z bazy, ale nie można go unieważnić przed wygaśnięciem. Sesja w bazie danych kosztuje jedno zapytanie na kontrolę i pozwala użytkownikom wylogować się ze wszystkich urządzeń. Wiele bibliotek pozwala wybrać.
Hostowane a samodzielnie utrzymywane
Clerk prowadzi za Ciebie bazę użytkowników, strony logowania i obsługę sesji, a Ty wstawiasz jego komponenty do layoutu. Oddajesz część kontroli i przy większej skali płacisz miesięczny rachunek, a w zamian zyskujesz szybkość i dopracowany interfejs od pierwszego dnia.
Better Auth i Auth.js działają wewnątrz Twojej aplikacji i zapisują do Twojej bazy danych. Dane i ekrany należą do Ciebie, ale na Twojej głowie są też wysyłka e-maili, procesy resetowania hasła i aktualizacje.
Jeśli już korzystasz z Supabase
Supabase Auth wiąże logowanie bezpośrednio z row level security w Postgres, więc polityka taka jak auth.uid() = user_id chroni dane na poziomie bazy. Pakiet @supabase/ssr przechowuje sesję w ciasteczkach, aby Server Components mogły ją odczytać.
Dokumentacja Supabase ostrzega, że getSession() zwraca niezweryfikowane dane. Zanim zaufasz tożsamości użytkownika, użyj getClaims(), które sprawdza podpis tokena, albo getUser(), które pyta serwer uwierzytelniania.
Własna implementacja
Przewodnik Next.js prowadzi przez nią krok po kroku: Server Action dla formularza, Zod do walidacji, bcrypt do haszowania i jose do podpisania siedmiodniowego ciasteczka sesji. To dobry sposób, by poznać wszystkie elementy.
Na produkcję ten sam przewodnik zaleca bibliotekę, bo ograniczanie liczby żądań, weryfikacja e-maili, łączenie kont i logowanie wieloskładnikowe szybko się sumują.
Minimalna konfiguracja każdej opcji
Clerk
Zainstaluj @clerk/nextjs i ustaw NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY oraz CLERK_SECRET_KEY. W Next.js 16 plik middleware to proxy.ts.
Supabase Auth
Klient serwerowy tworzony przy każdym żądaniu z magazynu ciasteczek, z użyciem klucza publikowalnego. getClaims() weryfikuje token, zanim mu zaufasz.
Better Auth
Podepnij handler pod trasę catch-all, a potem odczytuj sesję na serwerze z nagłówków żądania.
Auth.js (next-auth v5 beta)
auth.ts eksportuje handlers, auth, signIn i signOut. Ustaw AUTH_SECRET (npx auth secret go tworzy).
Własne podpisane ciasteczko sesji
Skrócona wersja wzorca z przewodnika Next.js: jose podpisuje zawartość, a ciasteczko ma HttpOnly, Secure i SameSite=Lax.
Gdzie sprawdzać sesję
Kontrole uwierzytelniania według miejsca (z przewodnika Next.js o uwierzytelnianiu)
Miejsce
Typ kontroli
Dlaczego
Optymistyczna, tylko ciasteczko
Szybkie przekierowania: działa przed renderowaniem, także przy prefetchach
Warstwa dostępu do danych
Bezpieczna
Jedna funkcja verifySession(), przez którą przechodzi każdy odczyt danych
Server Actions
Bezpieczna
Traktowane jak publiczne endpointy: sprawdź rolę przed zmianą danych
Route Handlers
Bezpieczna
401 po wylogowaniu, 403 przy niewłaściwej roli
Layouty
Unikaj
Nie renderują się ponownie przy nawigacji, więc kontrole mogą zostać pominięte
Clerk
Najszybsza droga do działającej strony logowania: użytkownicy są przechowywani w Clerk.
Supabase Auth
Użytkownicy są w Twoim Postgres w Supabase: płatne plany naliczają opłaty za użytkowników ponad wliczony limit.
Better Auth
Biblioteka w Twojej aplikacji, zapisuje do Twojej bazy danych, wtyczki do dodatkowych funkcji.
Opcja o długiej historii, teraz część Better Auth: v5 jest nadal publikowana jako beta.
Własne rozwiązanie
Pełna kontrola: piszesz każdy proces i dbasz o jego bezpieczeństwo.
Dane użytkowników zostają w bazie danych, którą kontroluję
Gotowe ekrany logowania i profilu
Brak opłaty za użytkownika u dostawcy uwierzytelniania
Logowanie powiązane z row level security w Postgres
Selektor opcji uwierzytelniania
Zaznacz ważne wymagania, a lista zachowa tylko opcje, które spełniają je wszystkie.
Wymagania
Żadna pojedyncza opcja nie spełnia wszystkich zaznaczonych wymagań. Odznacz jedno, aby porównać.