Come aggiungere il login alla tua app: password, magic link, Google e ruoli

Per aggiungere il login a un'app, scegli un metodo — email e password, magic link (un link di accesso monouso inviato via email) oppure «Accedi con Google» — e implementalo con una libreria di autenticazione collaudata o un provider ospitato, invece di costruirlo da zero. Poi decidi cosa può fare ciascun tipo di utente (ruoli), e fallo rispettare sul server per ogni pagina e ogni richiesta API. Le sessioni devono usare cookie sicuri, scadere e terminare correttamente al logout.

Questa guida passa in rassegna ogni scelta e i dettagli che distinguono un login funzionante da un login sicuro. Per i concetti alla base, vedi cos'è l'autenticazione.

Prima decidi: ti serve davvero il login?

Il login aggiunge attrito e responsabilità. Ti serve quando:

• Gli utenti hanno dati privati (le loro prenotazioni, documenti, fatture)
• Gli utenti possono modificare cose che altri vedranno
• Fai pagare l'accesso
• Persone diverse hanno bisogno di permessi diversi (proprietario, staff, cliente)

Potresti non averne bisogno per un sito di marketing, una directory pubblica o un modulo che ti invia solo un'email. Una lista d'attesa non richiede account; basta un campo email.

I quattro metodi di login più comuni

Molte app combinano due metodi: l'accesso con Google più i magic link via email è una coppia diffusa che copre la maggior parte delle persone senza memorizzare alcuna password.

Email e password

Se offri le password, questi punti sono irrinunciabili:

• Calcola l'hash delle password con un algoritmo lento pensato per le password. Le linee guida OWASP per la conservazione delle password raccomandano Argon2id, con scrypt, bcrypt o PBKDF2 come alternative. Non conservare mai le password in chiaro o con un hash generico veloce.
• Il reset della password usa un link casuale, monouso e con scadenza, inviato all'email verificata.
• Non rivelare quali email hanno un account. «Se questa email è registrata, abbiamo inviato un link di reset» è meglio di «Nessun account trovato».
• Limita la frequenza dei tentativi di login e di reset per rallentare l'indovinamento delle password.
• Consenti password lunghe e gestori di password; evita regole che impongono combinazioni di caratteri strane.

Magic link e codici monouso

Un magic link è un link di accesso inviato via email all'utente. Cliccandolo, l'utente accede. Un codice monouso è la stessa idea, ma digitata invece che cliccata.

• Link e codici scadono in fretta e funzionano una sola volta.
• Il link deve far accedere l'utente sul dispositivo in cui ha cliccato, e il token non deve restare nei log o negli strumenti di analytics.
• Ti serve un invio email affidabile — vedi come inviare email dalla tua app. Verifica con Gmail e Outlook e controlla la cartella dello spam.

Accedi con Google (e altri provider OAuth)

«Accedi con Google» usa OAuth e OpenID Connect: Google conferma chi è l'utente e comunica alla tua app la sua email e il suo nome. La configurazione, a settembre 2026, avviene nella sezione Google Auth Platform della Google Cloud Console:

1. Crea o seleziona un progetto e compila la pagina Branding — cosa vedono gli utenti nella schermata di consenso (nome dell'app, email di supporto, logo).
2. Nella pagina Clients, crea un client di tipo «Web application».
3. Aggiungi le tue origini JavaScript autorizzate e i redirect URI — gli indirizzi esatti su cui gira la tua app e a cui Google rimanda gli utenti dopo l'accesso.
4. Conserva client ID e client secret nei segreti della tua app.

Cose che di solito vanno storte, secondo la documentazione OAuth di Google:

• redirect_uri_mismatch: l'indirizzo di redirect deve corrispondere esattamente, incluso http contro https, le maiuscole e l'eventuale barra finale. Aggiungine uno per l'indirizzo di anteprima e uno per il tuo dominio live.
• HTTPS obbligatorio: i redirect URI devono usare HTTPS, eccetto localhost durante lo sviluppo.
• Il parametro state va verificato al ritorno per proteggere dal cross-site request forgery. Le librerie valide lo fanno per te.

Se chiedi solo le informazioni di base per l'accesso (nome, email, profilo), Google dice che la verifica dell'app non è obbligatoria. Chiedere l'accesso a Gmail, Drive o Calendar degli utenti è diverso e richiede la verifica.

Costruirlo o usare un provider?

I primi due sono entrambi ragionevoli. I provider ospitati gestiscono più cose per te, ma aggiungono una dipendenza e a volte un costo per utente attivo; verifica i prezzi attuali sui loro siti. Le librerie mantengono tutto nel tuo database, ma ti lasciano più da configurare correttamente. Qualunque scelta tu faccia, chiedi all'AI di usarla invece di scrivere a mano la logica di password o sessione.

Ruoli e permessi

Il login ti dice chi è una persona. I permessi decidono cosa può fare. All'inizio tienila semplice:

Regole più importanti dei nomi dei ruoli:

• Verifica sul server, ogni volta. Nascondere un pulsante nella pagina non impedisce a nessuno di chiamare direttamente l'API.
• Limita per proprietario. Un membro che richiede «prenotazione 123» dovrebbe ottenerla solo se è sua.
• Gli utenti non possono promuoversi da soli. Ignora i campi ruolo inviati dal browser negli aggiornamenti del profilo.
• Di default nessun accesso. Le nuove route devono richiedere il login, salvo tua decisione esplicita.

Verificalo con due account: accedi con uno, annota l'ID di un record, accedi con l'altro e prova ad aprirlo. La nostra checklist di sicurezza contiene il test completo.

Sicurezza della sessione

Dopo il login, l'app ricorda l'utente con una sessione — di solito un cookie. Le linee guida OWASP sulla gestione delle sessioni raccomandano:

• Cookie di sessione impostati con Secure (solo HTTPS), HttpOnly (non leggibili dagli script della pagina) e SameSite
• Un nuovo ID di sessione emesso al login, e di nuovo quando cambiano i privilegi
• Un timeout per inattività e una durata massima assoluta, applicati sul server
• Un logout che termina la sessione sul server, non si limita a cancellare il cookie
• Sessioni invalidate quando un utente cambia la password

Memorizzare i token di accesso nel local storage del browser è comune nelle guide, ma li espone a qualsiasi script in esecuzione nella pagina; per le app web i cookie sicuri sono di solito l'impostazione predefinita migliore.

Un prompt che copre l'essenziale

Aggiungi account utente a questa app. Gli utenti possono registrarsi e accedere con email e password, oppure con Google. Usa [libreria o provider] invece di codice di autenticazione personalizzato. Calcola l'hash delle password con Argon2id o bcrypt. Aggiungi il reset della password via email con un link monouso che scade dopo un'ora. Conserva le sessioni in cookie sicuri e HttpOnly. Proteggi /dashboard e ogni route /api così che solo gli utenti connessi possano usarle, e assicurati che gli utenti vedano solo i propri progetti. Aggiungi un ruolo «admin» che può vedere tutti gli utenti; solo gli admin possono accedere a /admin, verificato sul server.

Poi verifica: registrati, esci, accedi, reimposta la password, prova un URL privato da disconnesso e prova il record di un altro utente.

Errori comuni nel login costruito con l'AI

• Protezione solo nella pagina. La pagina reindirizza gli utenti disconnessi, ma l'API restituisce dati a chiunque.
• Segreti nel browser. I client secret OAuth e le chiavi admin del provider di autenticazione vanno sul server.
• URL di anteprima e live confusi. Il redirect URI di Google o il link di reset nell'email punta all'anteprima, così il login si rompe dopo la pubblicazione.
• Nessuna verifica dell'email. Chiunque può registrarsi come anyone@azienda.com. Verifica l'email prima di concedere qualsiasi cosa legata a quell'indirizzo.
• Testare solo il percorso felice. Prova password sbagliate, link scaduti e un secondo account.

Aggiungere il login in Mythex

Su Mythex, il login per gli utenti della tua app è qualcosa che aggiungi alla tua app — è separato dal tuo account Mythex. Mythex non fornisce un prodotto di autenticazione integrato, quindi porti una libreria o un provider di autenticazione e le sue chiavi:

1. Scegli un approccio — per esempio email e password conservate nel tuo database, oppure l'SDK di un provider ospitato.
2. Se conservi tu gli utenti, l'app ha bisogno di un database; chiedilo in chat oppure usa /database.
3. Metti le chiavi del provider nei segreti del progetto (/secrets o nelle impostazioni del progetto).
4. Usa un prompt simile a quello sopra, poi verifica nell'Anteprima. Per l'accesso con Google, aggiungi i redirect URI sia per l'anteprima sia per l'indirizzo pubblicato.

Vedi Aggiungere il login alla tua app nella documentazione. Se stai costruendo un prodotto a pagamento, come costruire un MVP SaaS tratta insieme account e fatturazione.

Domande