Autenticazione in Next.js: Auth.js vs Better Auth vs Clerk | We.Inc
Confronta Auth.js, Better Auth, Clerk, Supabase Auth e una sessione fatta in casa per Next.js 16, con il codice di setup per ciascuna e un selettore che restringe l'elenco alle tue esigenze.
Autenticazione in Next.js: le opzioni a confronto
Per la maggior parte delle app Next.js conviene scegliere una libreria invece di scrivere l'autenticazione da soli. Clerk è un servizio hosted ed è il più rapido da configurare, Supabase Auth è adatto alle app che usano già Supabase, e Better Auth o Auth.js tengono gli utenti nel tuo database. Qualunque scelta tu faccia, verifica di nuovo la sessione nel codice server, perché i controlli nel proxy da soli non proteggono i dati.
In sintesi
Opzione
Dove sono salvati gli utenti
Clerk
Sui server di Clerk
@clerk/nextjs, ClerkProvider, clerkMiddleware in proxy.ts
Supabase Auth
Nel tuo progetto Supabase
client @supabase/ssr più un proxy che aggiorna la sessione
Better Auth
Nel tuo database
istanza auth più app/api/auth/[...all]/route.ts
Auth.js (next-auth v5 beta)
Nel tuo database o in un cookie JWT
auth.ts più app/api/auth/[...nextauth]/route.ts
Fai da te
Nel tuo database
jose o iron-session, cookie httpOnly, un livello di accesso ai dati
La guida ufficiale di Next.js elenca dodici librerie di autenticazione compatibili, più scelta di quanta ne serva alla maggior parte delle persone. Questo confronto la riduce alle cinque strade che la maggior parte dei team valuta davvero, mostra il codice minimo per ciascuna nell'App Router e spiega i controlli che devi comunque alla tua app, qualunque libreria faccia accedere gli utenti.
Spunta i requisiti che contano per te, come tenere i dati degli utenti nel tuo database o avere schermate di accesso già pronte.
Il selettore nasconde le opzioni che non soddisfano tutti i requisiti spuntati.
Apri il codice di setup delle opzioni rimaste e confronta quanto dovresti scrivere.
Leggi la sezione sulla sicurezza prima di andare in produzione, qualunque opzione tu scelga.
Salva le sessioni in cookie impostati sul server con HttpOnly, Secure, SameSite e una scadenza, come consiglia la guida di Next.js.
Metti una funzione verifySession() in un unico file solo server e chiamala da pagine, Server Actions e Route Handlers.
Non affidarti a un layout per i controlli di autenticazione. I layout non vengono renderizzati di nuovo durante la navigazione lato client, quindi il controllo può essere saltato.
Tieni piccolo il payload della sessione: un id utente e un ruolo, mai un indirizzo email o un numero di telefono.
Genera i secret con openssl rand -base64 32 (o npx auth secret per Auth.js) e tienili nelle variabili d'ambiente.
Domande frequenti
NextAuth è ancora mantenuto?
Auth.js, il progetto prima chiamato NextAuth, dice sul proprio sito di essere ora parte di Better Auth. Il suo comando di installazione per Next.js è ancora npm install next-auth@beta. I nuovi progetti spesso partono direttamente con Better Auth, mentre le app Auth.js esistenti continuano a funzionare.
Posso proteggere le pagine solo con proxy.ts?
No. La documentazione di Next.js definisce ottimistici i controlli nel proxy: utili per reindirizzamenti rapidi basati su un cookie, ma non un confine di sicurezza. Verifica di nuovo la sessione vicino ai dati, perché le Server Functions e le route fuori dal matcher non passano mai dal proxy.
Qual è l'opzione più economica?
Le librerie che salvano gli utenti nel tuo database, come Better Auth o Auth.js, non hanno costi per utente; paghi il database e l'invio delle email. Supabase Auth include 50,000 utenti attivi mensili nel piano gratuito a ottobre 2026. Controlla la pagina dei prezzi di Clerk per la sua attuale soglia gratuita.
Funzionano con Next.js 16?
Sì. Clerk e Supabase documentano entrambi proxy.ts per Next.js 16 e middleware.ts per le versioni precedenti, e Better Auth offre un helper per i cookie nel proxy più un controllo completo della sessione per il codice server.
Sessioni stateless o su database?
Un cookie firmato (stateless) è più semplice e non richiede ricerche, ma non puoi revocarlo prima della scadenza. Una sessione su database costa una query per ogni controllo e permette agli utenti di uscire da tutti i dispositivi. Molte librerie ti lasciano scegliere.
Hosted o self-hosted
Clerk gestisce per te l'archivio degli utenti, le pagine di accesso e le sessioni, e tu inserisci i suoi componenti nel layout. In cambio della velocità e di un'interfaccia curata fin dal primo giorno rinunci a un po' di controllo e paghi una bolletta mensile quando cresci.
Better Auth e Auth.js girano dentro la tua app e scrivono nel tuo database. I dati e le schermate sono tuoi, ma sono tuoi anche l'invio delle email, i flussi di reset della password e gli aggiornamenti.
Se usi già Supabase
Supabase Auth collega l'accesso direttamente alla row level security di Postgres, quindi una policy come auth.uid() = user_id protegge i dati a livello di database. Il pacchetto @supabase/ssr salva la sessione nei cookie così i Server Components possono leggerla.
La documentazione di Supabase avverte che getSession() restituisce dati non verificati. Usa getClaims(), che controlla la firma del token, o getUser(), che interroga il server di autenticazione, prima di fidarti dell'identità dell'utente.
Scriverla da soli
La guida di Next.js ti accompagna passo passo con una Server Action per il modulo, Zod per la validazione, bcrypt per l'hashing e jose per firmare un cookie di sessione di sette giorni. È un buon modo per capire tutti i pezzi in gioco.
Per la produzione, la stessa guida consiglia una libreria, perché rate limiting, verifica dell'email, collegamento degli account e accesso a più fattori si accumulano in fretta.
Setup minimo per ogni opzione
Clerk
Installa @clerk/nextjs e imposta NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY e CLERK_SECRET_KEY. Su Next.js 16 il file del middleware è proxy.ts.
Supabase Auth
Un client server creato a ogni richiesta dal cookie store, usando la chiave pubblicabile. getClaims() verifica il token prima che tu te ne fidi.
Better Auth
Monta l'handler su una route catch-all, poi leggi la sessione sul server con gli header della richiesta.
Auth.js (next-auth v5 beta)
auth.ts esporta handlers, auth, signIn e signOut. Imposta AUTH_SECRET (npx auth secret ne crea uno).
Il tuo cookie di sessione firmato
Una versione breve dello schema della guida di Next.js: jose firma il payload e il cookie è HttpOnly, Secure e SameSite=Lax.
Dove controllare la sessione
Controlli di autenticazione per posizione (dalla guida all'autenticazione di Next.js)
Posizione
Tipo di controllo
Perché
Ottimistico, solo cookie
Reindirizzamenti rapidi; gira prima del rendering, anche sui prefetch
Livello di accesso ai dati
Sicuro
Un unico verifySession() da cui passa ogni lettura dei dati
Server Actions
Sicuro
Trattate come endpoint pubblici; controlla il ruolo prima di modificare
Route Handlers
Sicuro
401 se non autenticato, 403 se il ruolo è sbagliato
Layout
Da evitare
Non vengono renderizzati di nuovo durante la navigazione, quindi i controlli possono essere saltati
Clerk
Il modo più rapido per avere una pagina di accesso funzionante; gli utenti stanno su Clerk.
Supabase Auth
Gli utenti stanno nel tuo Postgres di Supabase; i piani a pagamento fatturano gli utenti oltre la quota inclusa.
Better Auth
Libreria nella tua app, scrive nel tuo database, plugin per le funzioni extra.
Opzione di lunga data, ora parte di Better Auth; la v5 è ancora pubblicata come beta.
Fai da te
Controllo totale; scrivi ogni flusso e lo mantieni sicuro tu.
I dati degli utenti restano in un database che controllo io
Schermate di accesso e profilo già pronte
Nessun costo per utente dal provider di autenticazione
Accesso collegato alla row level security di Postgres
Selettore delle opzioni di autenticazione
Spunta i requisiti che contano e l'elenco mantiene solo le opzioni che li soddisfano tutti.
Requisiti
Nessuna opzione da sola soddisfa tutti i requisiti spuntati. Togline uno per confrontare.