Cos'è l'autenticazione? Login, sessioni e OAuth spiegati

L'autenticazione è il modo in cui un'app verifica chi è un utente — di solito controllando qualcosa che l'utente conosce (una password), qualcosa che possiede (un codice inviato al telefono o via email) oppure un'identità presa da un servizio di fiducia (come «Accedi con Google»). Una volta autenticato l'utente, l'app lo ricorda con una sessione o un token, così non deve accedere a ogni pagina. Decidere cosa può fare quell'utente riconosciuto è un passaggio separato, chiamato autorizzazione.

Perché conta quando costruisci con l'AI

Aggiungere il login è una delle richieste più comuni che le persone fanno a un AI builder, ed è una delle più facili da sbagliare in modo sottile. Una pagina di login è semplice da generare. La parte difficile è tutto ciò che la circonda:

Le password vengono memorizzate in modo sicuro?
Ogni pagina privata e ogni endpoint API verifica davvero chi sta chiedendo?
Un cliente registrato può vedere i dati di un altro cliente cambiando un numero nell'URL?
Cosa succede quando qualcuno dimentica la password?

Un'app può sembrare perfettamente sicura pur fallendo in tutti questi punti. Capire le parti in movimento ti permette di porre le domande giuste e verificare le cose giuste.

Un'analogia quotidiana

Pensa al check-in in un hotel.

Alla reception mostri un documento. Questa è l'autenticazione: dimostrare chi sei. L'addetto ti consegna poi una tessera magnetica. Quella tessera è la tua sessione: per tutto il soggiorno non mostri più il documento; usi la tessera.

La tessera apre la tua camera, la palestra e l'ascensore fino al tuo piano — ma non le camere degli altri ospiti né l'ufficio del personale. Questa è l'autorizzazione: a cosa la tua identità può accedere. Se perdi la tessera, l'hotel può disattivarla alla reception (revocare la sessione). Quando fai il check-out, smette di funzionare (logout, o scadenza).

«Accedi con Google» è come se un hotel accettasse una lettera di un partner di fiducia che dice «questa è la persona», invece di controllare lui stesso il tuo documento.

I principali metodi di accesso

Metodo	Come funziona	Vantaggi	Svantaggi
Email + password	L'utente sceglie una password; l'app ne memorizza un hash	Familiare, nessuna dipendenza esterna	Devi memorizzare gli hash in modo sicuro e gestire i reset
Link magico / codice monouso	L'app invia via email un link o un codice che accede	Nessuna password da rubare o dimenticare	Dipende dalla consegna delle email; accesso più lento
Login social (OAuth / OpenID Connect)	L'utente accede con Google, Apple, GitHub, ecc.	Veloce per gli utenti; tu non memorizzi password	Configurazione per ogni fornitore; utenti senza quegli account
Fornitore di autenticazione ospitato	Un servizio come Clerk, Auth0 o Supabase Auth gestisce registrazione, login e reset	Meno lavoro di sicurezza per te	Costo mensile su larga scala; un'altra dipendenza
Autenticazione a più fattori (MFA / 2FA)	Un secondo controllo dopo il primo, come un codice da app di autenticazione	Molto più difficile da violare	Un po' più di attrito

Come devono essere memorizzate le password

Un'app sicura non memorizza mai la tua password vera. Memorizza invece un hash: il risultato di una funzione unidirezionale che trasforma la password in una stringa di lunghezza fissa. Quando accedi, l'app applica l'hash a ciò che hai digitato e confronta il risultato con l'hash memorizzato.

Due dettagli rendono tutto questo sicuro:

Un sale (salt) — un valore casuale aggiunto a ogni password prima dell'hash, così due persone con la stessa password ottengono hash diversi, e le tabelle di ricerca precalcolate non servono a nulla.
Un algoritmo lento pensato per le password — come Argon2, bcrypt o scrypt. Gli hash generici come MD5 o SHA-256 sono troppo veloci da soli; un attaccante potrebbe provare miliardi di tentativi.

L'hashing non è la stessa cosa della crittografia. I dati cifrati possono essere decifrati con una chiave; un hash di password è progettato per non essere reversibile affatto.

Sessioni vs token

Dopo il login, l'app deve riconoscerti a ogni richiesta. Ci sono due approcci comuni.

	Sessione (cookie)	Token (es. JWT)
Cosa tiene il browser	Un ID di sessione casuale in un cookie	Un token firmato che contiene dati dell'utente e una scadenza
Dove vive lo stato di accesso	Sul server, in un database o in un archivio	Dentro il token stesso
Disconnettere qualcuno ovunque	Facile: eliminare la sessione sul server	Più difficile: il token resta valido fino alla scadenza, a meno di tenere una lista di blocco
Uso tipico	Le app web tradizionali	API, app mobile, servizi che comunicano tra loro

Per i cookie contano tre impostazioni: HttpOnly (il JavaScript della pagina non può leggere il cookie), Secure (inviato solo tramite HTTPS) e SameSite (limita l'invio su richieste da altri siti). Memorizzare i token nel localStorage del browser è comune, ma li espone a qualsiasi script che gira sulla pagina.

OAuth e «Accedi con Google»

OAuth 2.0 è uno standard per l'autorizzazione delegata: permette a un'app di ottenere accesso limitato al tuo account su un altro servizio — per esempio leggere il tuo Google Calendar — senza mai vedere la tua password Google. Vieni indirizzato a Google, approvi permessi specifici (chiamati scope), e Google dà all'app un token solo per quei permessi.

OAuth da solo era progettato per concedere l'accesso, non per dire chi sei. OpenID Connect (OIDC) è un livello sopra OAuth 2.0 che aggiunge l'identità, ed è ciò che usano «Accedi con Google» o «Accedi con Apple». Per configurarlo registri la tua app presso il fornitore e ottieni un client ID e un client secret; il secret resta sul tuo server.

Immagina di costruire un portale in cui i clienti di un'agenzia di design vedono i propri progetti e le fatture.

Autenticazione: i clienti accedono con email e link magico, quindi non ci sono password da gestire. Il personale dell'agenzia accede con account Google Workspace.
Ruoli: ogni utente ha un ruolo — client o staff.
Regole di autorizzazione:

Azione	Cliente	Personale
Vedere i progetti della propria azienda	Sì	Sì
Vedere i progetti di altre aziende	No	Sì
Caricare un file in un progetto	Solo nei propri progetti	Sì
Segnare una fattura come pagata	No	Sì

Dove viene applicato: sul server, per ogni richiesta. Il server cerca l'utente connesso e restituisce solo i progetti in cui project.company_id corrisponde all'azienda dell'utente. Nascondere il pulsante «Segna come pagata» non basta — l'endpoint stesso deve rifiutare la richiesta.

Termini comuni spiegati

Termine	Significato
Autenticazione (AuthN)	Verificare chi è una persona.
Autorizzazione (AuthZ)	Decidere cosa le è permesso fare.
Sessione	Il fatto che l'app ricordi che sei connesso, tra una richiesta e l'altra.
Cookie	Un piccolo pezzo di dati che il browser rimanda al sito con ogni richiesta.
JWT	JSON Web Token: un token firmato e compatto che contiene informazioni come l'ID utente e la scadenza.
Ruolo / permesso	Etichette come `admin` o `member` che decidono l'accesso.
MFA / 2FA	Richiedere una seconda prova, come un codice da un'app di autenticazione.
SSO	Single sign-on: un unico accesso (spesso un account aziendale) per molte app.
401 vs 403	«Chi sei?» (non autenticato) contro «Non puoi farlo» (non autorizzato).

Errori comuni e idee sbagliate

Controllare i permessi solo nella pagina. Se il browser nasconde un pulsante ma l'API non verifica, chiunque può chiamare l'API direttamente.
Fidarsi degli ID presi dall'URL. /invoices/1042 deve verificare che la fattura 1042 appartenga all'utente connesso.
Inventare la propria crittografia. Usa librerie o fornitori noti; non lasciare che l'AI inventi uno schema di hashing.
Reset della password debole. I link di reset devono essere monouso, scadere in fretta e non rivelare se un'email ha un account.
Confondere il tuo login con quello del tuo builder. Gli utenti della tua app sono separati dal tuo account sullo strumento con cui la costruisci.
Nessun limite di tentativi sul login. Senza, un attaccante può provare password all'infinito.

Cosa chiedere al tuo AI builder

«Aggiungi registrazione e login usando [una libreria o un fornitore noto]. Non scrivere un hashing delle password personalizzato.»
«Memorizza le password con hash bcrypt o Argon2.»
«Usa cookie HttpOnly e Secure per la sessione.»
«Aggiungi i ruoli: admin e member. Elenca ogni endpoint e quali ruoli possono chiamarlo.»
«Fai rispettare sul server che gli utenti possano leggere e modificare solo i propri record. Poi mostrami come l'hai verificato.»
«Aggiungi il reset della password con link monouso che scadono dopo un'ora.»
«Limita i tentativi di login.»

Poi verificalo tu: crea due account e prova a raggiungere i dati di uno mentre sei connesso con l'altro. La nostra guida per aggiungere il login e la checklist di sicurezza vanno oltre.

Autenticazione in Mythex

Mythex non fornisce un prodotto di autenticazione integrato per gli utenti della tua app; scegli un approccio — email e password memorizzate nel database del progetto, oppure l'SDK di un fornitore ospitato — e chiedi all'agente di aggiungerlo. Le chiavi del fornitore vanno nei segreti del progetto, non in chat. Questo è separato da come accedi a Mythex stesso. La ricetta della documentazione su come aggiungere il login alla tua app contiene un prompt di partenza che puoi adattare, e cos'è un'API spiega dove vivono quei controlli lato server.

Domande

Qual è la differenza tra autenticazione e autorizzazione?

L'autenticazione verifica chi sei, per esempio controllando la tua password. L'autorizzazione decide cosa ti è permesso fare una volta riconosciuto, come vedere la pagina di amministrazione o modificare la prenotazione di qualcun altro. Un'app ha bisogno di entrambe.

Cos'è OAuth?

OAuth 2.0 è uno standard che permette a un'app di ottenere accesso limitato al tuo account su un altro servizio senza vedere la tua password. «Accedi con Google» usa OpenID Connect, un livello di identità costruito sopra OAuth 2.0, quindi l'app scopre chi sei tramite Google.

La mia app deve memorizzare le password?

Mai in chiaro. Se usi il login con email e password, le password devono essere memorizzate come hash con sale, creati con un algoritmo lento progettato per le password, come Argon2 o bcrypt. Molte app evitano il problema usando un fornitore di autenticazione ospitato, il login con i social o link magici via email.

Sessioni o token — quale dovrebbe usare la mia app?

Funzionano entrambi. Una sessione memorizza lo stato di accesso sul server e dà al browser un ID casuale in un cookie, che è facile da revocare. Un token come un JWT contiene già informazioni firmate, e si adatta alle API e ai client mobile, ma è più difficile da annullare prima della scadenza. Per una tipica app web, le sessioni basate su cookie sono un'impostazione predefinita valida.