Supabase Auth è il sistema di login integrato in Supabase: conserva gli utenti nel database Postgres del vostro progetto, li fa accedere con password, magic link, codice monouso o un provider come Google, ed emette la sessione che le regole del database leggono. Per aggiungere il login a una web app, chiedete al vostro creatore di app con IA i metodi di accesso e i ruoli, poi controllate tre impostazioni nella dashboard di Supabase: il Site URL, i redirect URL e il mittente delle email.
Questa guida spiega cosa fa ogni parte, quali scelte contano e quali frasi inserire nel prompt. Per le regole di accesso vere e proprie, leggete la nostra guida alla row level security di Supabase.
Cosa fa e cosa non fa Supabase Auth
Supabase Auth dimostra chi è un utente; non decide cosa può vedere. La sua documentazione elenca i metodi di accesso: password, magic link, password monouso, login social (Apple, Google, GitHub e qualsiasi provider OAuth2 o OIDC), telefono tramite provider come Twilio e single sign-on aziendale SAML. I dati degli utenti risiedono in uno schema speciale del vostro database Postgres.
Ciò che un utente può fare è un secondo livello. Il client Supabase invia il token dell'utente a ogni richiesta, e le policy di row level security del database lo usano per filtrare le righe. L'autenticazione risponde a "chi è questa persona?", le policy rispondono a "quali righe può leggere o modificare?". Un'app con login ma senza policy è aperta a tutti.
Quale metodo di accesso scegliere
Scegliete il metodo che corrisponde alle abitudini dei vostri utenti: Google per un pubblico consumer o startup, email e password per gli strumenti aziendali, magic link quando le persone accedono di rado. Ognuno ha un costo, riassunto qui sotto.
| Metodo | Adatto a | Vantaggi | Svantaggi |
|---|---|---|---|
| Email e password | Strumenti aziendali, portali clienti | Familiare, funziona con qualsiasi indirizzo email, nessuna terza parte | Servono email di conferma e di reset; gli utenti dimenticano le password |
| Magic link o codice via email | Accessi rari, clienti poco tecnici | Nessuna password da conservare o dimenticare | Ogni accesso invia un'email, quindi contano la recapitabilità e i limiti di invio |
| OAuth (Google, GitHub) | App consumer, startup, strumenti per sviluppatori | Un clic, nessun flusso di reset password, nessuna email da inviare | Dovete creare le credenziali del provider e registrare il redirect URL; non tutti i clienti hanno l'account |
| Codice via telefono | Mercati in cui il telefono è l'identità | Veloce da mobile | Serve un account presso un provider SMS, e ogni messaggio è fatturato da quel provider |
| SSO aziendale (SAML) | Vendita a grandi aziende | Le aziende gestiscono gli accessi in modo centralizzato | Configurazione per ogni cliente; verificate i requisiti del piano nella pagina prezzi di Supabase |
Conferma dell'email e reset della password
Con la conferma dell'email attiva, un nuovo utente non può accedere finché non clicca il link nel messaggio. La pagina di configurazione di Supabase precisa che, se la disattivate, l'email viene considerata confermata senza alcuna verifica. Lasciatela attiva per qualsiasi app con utenti reali: senza, chiunque può creare un account con un indirizzo che non è il suo.
Il reset della password funziona allo stesso modo: l'utente chiede un link, riceve un'email e atterra su una pagina della vostra app dove sceglie una nuova password. Entrambi i flussi dipendono da due cose che controllate voi: le impostazioni di reindirizzamento qui sotto e il mittente delle email. Se un link di conferma apre "localhost" o una pagina di errore, la causa è quasi sempre nelle impostazioni di reindirizzamento.
Sessioni: cosa succede dopo il login
Dopo il login, Supabase consegna al browser un access token di breve durata e un refresh token, e la libreria client li rinnova senza chiedere all'utente di accedere di nuovo. Secondo la documentazione sulle sessioni, l'access token è un JWT che scade dopo 1 ora per impostazione predefinita, e ogni refresh token può essere usato una sola volta. Se un vecchio refresh token viene riutilizzato fuori da una breve finestra, l'intera sessione viene terminata.
Per chi usa un creatore di app, il punto pratico è che raramente scrivete codice per le sessioni. Chiedete "mantieni gli utenti connessi" e "reindirizza alla pagina di login quando si è disconnessi", e l'app generata usa la libreria client per il resto.
auth.users e tabella profiles
Tenete il record di login in auth.users e tutto il resto sulla persona in una tabella vostra, di solito chiamata profiles. La guida di Supabase sulla gestione dei dati utente ne spiega il motivo: lo schema auth non è esposto nell'API automatica, quindi la vostra app non può leggerlo direttamente. Lo schema consigliato è una tabella pubblica profiles il cui id fa riferimento ad auth.users con on delete cascade, con la row level security attivata, e un trigger che crea la riga del profilo dopo ogni registrazione.
La stessa guida avverte che un trigger che fallisce può bloccare le registrazioni, quindi testatelo con un vero nuovo account dopo ogni modifica alla tabella. È una causa frequente dell'errore "Database error saving new user" dopo che un'IA ha modificato lo schema.
Ruoli: admin, membro, cliente
Conservate il ruolo in una tabella vostra, non nel record di login, e lasciate che sia la row level security a farlo rispettare. Una colonna come role su profiles funziona per una sola organizzazione. Quando una persona può appartenere a più aziende o workspace, usate invece una tabella memberships (utente, organizzazione, ruolo), così la stessa persona può essere admin in una e cliente in un'altra.
Nascondere una voce di menu ai clienti non è sicurezza: è il database a dover rifiutare la richiesta. Una policy come "un cliente può leggere solo le fatture il cui client_id corrisponde alla sua appartenenza" lo fa. Non lasciate mai che gli utenti modifichino la propria colonna del ruolo; la policy su profiles deve consentire di aggiornare nome e avatar ma non il ruolo.
Registrazione solo su invito per strumenti interni e portali
Per uno strumento interno o un portale clienti, disattivate la registrazione aperta e create gli account solo su invito. Supabase ha l'impostazione "Allow new users to sign up"; quando è disattivata, possono accedere solo gli utenti già esistenti. L'invito vero e proprio, che crea l'utente, assegna il ruolo e invia l'email, deve essere eseguito sul server, in una edge function, perché richiede una chiave segreta che non deve mai arrivare al browser.
Il flusso da richiedere: un admin inserisce un'email e un ruolo, il server crea l'utente e la riga di appartenenza, e la persona invitata riceve un link per impostare una password. Le nostre guide agli strumenti interni e ai portali clienti mostrano dove si inserisce tutto questo in un'app completa.
Site URL e redirect URL
Il Site URL è l'indirizzo predefinito a cui Supabase rimanda gli utenti, e i redirect URL sono un elenco di altri indirizzi consentiti. La documentazione sui redirect URL spiega che il Site URL parte come http://localhost:3000 e va cambiato con l'indirizzo di produzione, perché le conferme via email e i reset della password dipendono da esso.
Aggiungete ogni indirizzo reale da cui la vostra app è servita: il dominio di produzione, il dominio personalizzato se ne avete uno e ogni indirizzo di anteprima su cui fate test. La documentazione consiglia percorsi esatti in produzione e caratteri jolly soprattutto per lo sviluppo locale e le anteprime. L'errore classico è un'app pubblicata le cui email puntano ancora a localhost, oppure un dominio personalizzato aggiunto dopo e mai registrato.
Limiti delle email e SMTP personalizzato
Il mailer integrato di Supabase è solo per i test: a novembre 2026 la sua documentazione indica un limite di 2 messaggi all'ora, consegna solo agli indirizzi del team della vostra organizzazione e nessuna garanzia di recapito. Questi numeri possono cambiare senza preavviso, quindi leggete la pagina sull'SMTP personalizzato prima del lancio.
Prima dell'arrivo degli utenti reali, collegate il vostro provider (la pagina cita Resend, AWS SES, Postmark, SendGrid, ZeptoMail e Brevo come esempi). La stessa pagina precisa che l'SMTP personalizzato parte da 30 messaggi all'ora, modificabili nella pagina dei rate limit, e consiglia di autenticare il dominio di invio con DKIM, SPF e DMARC. Se il vostro primo utente di prova non riceve l'email di conferma, il motivo è questo, non un bug dell'app.
Come lo configura Cadrant
Cadrant, il nostro creatore di app, usa Supabase Auth in un progetto Supabase che appartiene al vostro account Supabase, quindi gli account degli utenti restano vostri. Secondo la nostra documentazione sull'autenticazione, genera le pagine di login e di registrazione, configura la registrazione con email e password, protegge le route che richiedono una sessione e gestisce le sessioni. I provider OAuth come Google li attivate voi nella dashboard di Supabase, in Authentication, Providers.
L'IA scrive le migrazioni con la row level security sulle tabelle per utente e può leggere lo schema e le policy attuali prima di modificarli. I ruoli si descrivono nel prompt e si conservano in colonne o tabelle del vostro database. I segreti, come la chiave di un provider di email, restano in variabili d'ambiente dietro le edge function. Limiti da conoscere: Site URL, redirect URL, credenziali dei provider e SMTP personalizzato sono impostazioni di Supabase che verificate voi, e dovete testare ogni ruolo a mano prima di invitare i clienti. Vedete anche la nostra panoramica su Supabase con un creatore di app con IA.
Frasi da incollare nel vostro creatore di app con IA
Descrivete le persone e le regole, non il codice. Queste frasi funzionano nella maggior parte dei creatori di app:
- "Aggiungi il login con email e password e con Google. Gli utenti devono confermare l'email prima di accedere."
- "Crea una tabella profiles collegata agli utenti di autenticazione, compilata automaticamente alla registrazione, con una colonna role (admin, membro, cliente). Gli utenti possono modificare il nome ma mai il ruolo."
- "La registrazione è chiusa. Solo un admin può invitare un utente via email e scegliere il suo ruolo, da una funzione lato server."
- "Un cliente vede solo i propri record. Un membro vede tutto il team. Un admin vede tutto e gestisce gli utenti. Fai rispettare tutto questo con la row level security, non solo nell'interfaccia."
- "Aggiungi un link Password dimenticata e una pagina per impostare una nuova password. Reindirizza alla pagina di login gli utenti disconnessi."