Lascia che un sistema possieda l'identità
Il form di login raccoglie una richiesta. Il sistema di autenticazione decide se quella richiesta stabilisce un'identità ed emette la sessione di cui il resto dell'applicazione si fida. Tenere questa responsabilità in un solo posto impedisce a ogni route di inventare la propria interpretazione di un utente connesso.
supastack compone Better Auth per identità e gestione delle sessioni. Il codice applicativo risolve la sessione alle frontiere protette e la collega a un workspace. L'interfaccia può mostrare stati di accesso utili, ma lo stato client non deve diventare prova che un'operazione è autorizzata.
La regola deve valere su ogni superficie che il prodotto distribuisce. I client web, mobile e desktop dovrebbero consumare la stessa decisione di identità invece di implementarla tre volte — tre interpretazioni di «connesso» sono il luogo da cui arrivano i bug sugli account.
Scegli i metodi di accesso con criterio
Ogni metodo scambia attrito con superficie d'attacco e una dipendenza esterna. Le password richiedono flussi di reset e rate limiting. I magic link e i codici monouso dipendono dalla recapitabilità delle email. OAuth delega l'identità a provider come Google, GitHub o Apple — ed eredita le loro interruzioni, le loro schermate di consenso e le loro regole di callback.
supastack li compone tramite Better Auth — OTP via email, password, magic link, OAuth, con due fattori e passkey disponibili — dietro un'unica decisione di identità. Distribuisci l'insieme più piccolo di cui il tuo pubblico ha davvero bisogno; ogni metodo aggiuntivo è un altro percorso di callback, un altro modo di fallire e un altro flusso da verificare prima del lancio. La guida all'autenticazione copre il cablaggio.
Quando una persona può accedere in più di un modo, decidi come i metodi si uniscono. Un account Google e un magic link via email che risolvono allo stesso indirizzo dovrebbero approdare a un'unica identità, non a due. Le regole di collegamento degli account fanno parte della decisione di identità, e sbagliarle crea utenti duplicati che riaffiorano mesi dopo come dati misteriosamente spariti.
Le sessioni sono la credenziale che conta
Dopo l'accesso, la sessione — non la password — è ciò che ogni richiesta trasporta. Le sue regole di scadenza, conservazione e invalidazione definiscono la vera postura di sicurezza. Una sessione che sopravvive al logout, o una che un membro rimosso dal workspace può continuare a usare, è un fallimento di autenticazione che nessuna schermata di login elegante può riparare.
Decidi il ciclo di vita in anticipo: quanto vivono le sessioni, se gli utenti possono vedere e revocare le loro sessioni attive, e cosa fanno a quelle sessioni un cambio password, un cambio email o una rimozione dal workspace. La gestione delle sessioni esiste come modulo nel kit proprio perché queste decisioni sono facili da rimandare e costose da adattare dopo.
Collega la sessione al record richiesto
Essere connessi non concede accesso a ogni record. Risolvi il workspace dell'utente lato server e includi quel confine in letture e mutazioni. Un identificatore di attività o un link di ripresa è un riferimento al lavoro, non un permesso di recuperarlo — il post sui confini dei workspace copre in dettaglio quel lato della frontiera.
Risolvi la delimitazione in un ordine fisso: autentica la sessione, carica l'appartenenza, poi leggi o scrivi con quel contesto di workspace — mai il contrario. Il middleware può reindirizzare un visitatore anonimo, ma non può autorizzare l'operazione; il controllo appartiene alla server action o al route handler dove il record viene toccato.
Gli account hanno un ciclo di vita, non solo un inizio
Il provisioning è il primo test di quella frontiera. Quando un utente si registra, i record di workspace e possesso che seguono devono poter essere creati più di una volta in sicurezza — gli hook del ciclo di vita possono essere ripetuti da provider, retry o strumenti di supporto. Un evento duplicato dovrebbe essere un no-op, non un'organizzazione duplicata.
La fine del ciclo di vita merita la stessa cura. Cambi di email, reset delle password, rimozione di membri, eliminazione dell'account ed esportazione dei dati sono ciascuno piccoli flussi con i propri casi di abuso — un link di reset che funziona due volte, un'esportazione che fa trapelare i record di un collega. supastack include esportazione GDPR e gestione delle sessioni per questo motivo; qualunque cosa tu usi come base, metti a budget i flussi noiosi.
Testa il ciclo di vita, compresa la fine
Un test di login riuscito è utile ma incompleto. Esercita credenziali non valide, codici di verifica scaduti o riusati, richieste anonime e accesso tra workspace. Verifica che il logout invalidi la sessione e che un client di ritorno non possa continuare a usare una schermata precedentemente autorizzata per lavoro protetto.
Distingui i test degli handler dall'accettazione in deployment. Un adattatore in memoria può stabilire la semantica di un vero handler di auth senza dimostrare la persistenza Postgres o un callback del provider. Verifica l'origin configurato, il percorso di callback, il ripristino della sessione e il logout con le dipendenze deployate prima di affermare che il flusso completo di login funziona.
- Credenziali non valide e codici di verifica scaduti o riusati vengono rifiutati.
- Le richieste anonime e tra workspace non ricevono dati posseduti.
- Il logout invalida la sessione — un client obsoleto non può continuare ad agire.
- I record provisionati restano idempotenti quando gli hook del ciclo di vita si ripetono.
- I callback dei provider reali funzionano sull'origin configurato — verificato, non presunto.
Domande frequenti sull'autenticazione
Le domande qui sotto emergono quando il form di login è finito e il sistema deve continuare a funzionare.
- Il middleware basta a proteggere le route? — Il middleware è un comodo redirect, non un livello di autorizzazione. Ogni server action e route risolve da sé sessione e workspace; i guard a livello di pagina nascondono schermate senza autorizzare operazioni.
- Costruisco l'auth da solo o uso una libreria? — La semantica delle sessioni è raramente il punto in cui un SaaS si differenzia. Una libreria mantenuta come Better Auth dietro confini di modulo chiari ti dà primitive testate tenendo nel tuo codice le decisioni che contano — delimitazione, ciclo di vita.
- Come si relazionano sessioni e workspace? — La sessione identifica la persona; il workspace identifica i record che può toccare. Risolvi l'appartenenza sul server a ogni richiesta e non fidarti mai di un ID di workspace inviato dal client.
- Cosa si aspettano i clienti B2B dall'autenticazione? — Workspace di team con ruoli, accesso OAuth, visibilità e revoca delle sessioni e una traccia di audit. Due fattori e passkey sono sempre più attese per i ruoli admin.
- Cosa rompe l'autenticazione in produzione? — Di solito i bordi: un URL di callback che esiste solo in locale, un hook che provisiona due volte, una sessione che sopravvive a un'appartenenza. Testa la fine dei flussi, non solo l'inizio.