> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # Autenticazione Metodi di accesso, sessioni e sicurezza dell'account. ## Crea e verifica un account reale Autenticarsi significa dimostrare chi sta utilizzando l'app. Avviare Postgres ed eseguire prima le migrazioni utilizzando la guida del database, quindi lasciare in esecuzione il server Web. Apri http://localhost:3000/auth, scegli la registrazione tramite e-mail/password, inserisci il tuo nome, e-mail e password e invia. Conserva EMAIL_PROVIDER=local per questo primo test. Quando un flusso richiede un codice email, apri http://localhost:3000/mail-preview in un'altra scheda del browser, trova il messaggio più recente per quell'indirizzo e copiane nuovamente il codice nel modulo di accesso. Richiedi un nuovo codice se scade. Questi messaggi rimangono nella posta in uscita locale; controllando ripetutamente una casella di posta esterna non li troverà. Esci, quindi accedi nuovamente per verificare che l'account supportato dal database funzioni. Se la registrazione segnala una connessione al database o un errore di tabella mancante, completa la configurazione del database invece di abilitare l'accesso social. I pulsanti Google, GitHub, Apple, X e Microsoft necessitano della propria applicazione provider e delle impostazioni di richiamata; abilitarne uno solo dopo aver completato la guida del fornitore. Better Auth è il motore predefinito fornito e non richiede un account di autenticazione a pagamento per l'accesso e-mail locale. [Avvia Postgres prima di creare un account](https://supastack.dev/it/docs/web/database.md) [Utilizzo e risoluzione dei problemi relativi ai codici di accesso e-mail](https://supastack.dev/it/docs/web/setup-ai.md) [Configura accesso Google](https://supastack.dev/it/docs/web/setup-oauth.md) [Aggiungi l'accesso con Google](https://supastack.dev/it/docs/web/google-sign-in.md) [Aggiungi l'accesso con GitHub](https://supastack.dev/it/docs/web/github-sign-in.md) [Aggiungi l'accesso con Apple](https://supastack.dev/it/docs/web/apple-sign-in.md) ## Scegli i metodi di login abilitati La base include email/password, OTP e auth social configurabile. Better Auth possiede identità e sessioni, mentre l'applicazione compone la configurazione dei provider e la consegna transazionale degli OTP. Abilita solo i provider social che hai configurato. I segreti client dei provider e il segreto di auth restano sul server. ## Collega l'identità a un workspace Gli handler autenticati risolvono lo stato della sessione prima di accedere ai record del workspace. Il provisioning del workspace deve restare idempotente così che ripetere un hook del ciclo di vita non crei record di possesso duplicati. ## Verifica il comportamento della sessione Testa login, OTP non validi o scaduti, consumo monouso, logout e accesso anonimo negato. I test con adattatore in memoria coprono la semantica degli handler; la persistenza del database di produzione e i callback reali dei provider richiedono accettazione separata. ## Installazione e configurazione Better Auth è il motore predefinito (AUTH_PROVIDER=better-auth); un motore Auth.js è disponibile per i team che si standardizzano su di esso. I metodi abilitati sono dichiarati per provider: email/password, codici monouso consegnati via email transazionale e social sign-in per Google, Apple, GitHub, Microsoft e Twitter. Ogni provider social si attiva con il suo flag AUTH__ENABLED più il client id e secret corrispondenti. Il secret di autenticazione, i secret dei provider e le chiavi di firma della sessione sono configurazione solo server. ``` AUTH_PROVIDER=better-auth AUTH_SECRET=generate-a-long-random-value AUTH_GOOGLE_ENABLED=true GOOGLE_CLIENT_ID=… GOOGLE_CLIENT_SECRET=… ``` ## Flusso di implementazione La superficie /auth renderizza i metodi configurati; il server compone il motore in auth-runtime e risolve la sessione a ogni confine protetto. Un primo accesso riuscito provisiona il workspace personale del membro in modo idempotente — hook di lifecycle ripetuti non devono mai creare un secondo record di proprietà. La sicurezza dell'account vive sotto /settings/security: cambio password, sessioni attive e passkey dove la build le abilita. Mantieni ripristino sessione, revoca al logout e diniego cross-workspace come comportamento applicato dal server, non come stato dell'interfaccia. ## Verifica e risoluzione dei problemi Esercita l'accesso, codici OTP non validi e scaduti, consumo monouso, cerimonie passkey su origini HTTPS, ritorni di callback social, logout e diniego anonimo. Registra ogni URI di redirect del provider prima di testare i callback, e verifica che una sessione revocata non possa più eseguire lavoro protetto. ## Successivo [Organizzazioni e inviti](https://supastack.dev/it/docs/web/organizations.md)