Ogni piattaforma di questo sito dichiara di “avere l’autenticazione”. Questo termine copre sia un modulo di accesso senza nulla dietro sia un insieme completo di flussi già pronti di recupero, verifica e gestione delle sessioni. Chi si ferma alla semplice casella spuntata scopre la differenza dopo il lancio, di solito quando un utente reale rimane bloccato fuori e non esiste alcuna pagina di reimpostazione della password a cui indirizzarlo. Questa guida analizza cosa dovrebbe davvero significare questa dichiarazione, e come verificarla prima di firmare, in relazione al criterio Sicurezza e controllo degli accessi valutato su /methodology.
La casella spuntata nasconde otto decisioni distinte
“Avere l’autenticazione” è in realtà un insieme di flussi indipendenti, e una piattaforma può fornirne alcuni mentre tralascia silenziosamente gli altri:
- Pagine di accesso e registrazione - la parte visibile che ogni piattaforma mostra nelle demo.
- Reimpostazione della password - un flusso in autoservizio, non un ticket di assistenza, per l’account che non avete creato voi.
- Password a uso singolo (OTP) - codici via e-mail o SMS come alternativa a una password memorizzata.
- Link magici - accesso senza password tramite un unico link inviato via e-mail.
- Autenticazione a due fattori (2FA) - un secondo passaggio di verifica oltre la password.
- SSO (SAML/OpenID) - accesso tramite il provider di identità già esistente dell’acquirente, comune negli acquisti aziendali.
- Registrazione con restrizione di dominio o solo su invito - controllare chi può creare un account, non solo chi può accedere una volta che ne ha già uno.
- Gestione delle sessioni e logout forzato - per quanto tempo una sessione resta valida e se un amministratore può terminarla.
Una piattaforma che «ha l’autenticazione» potrebbe fornire tutti e otto gli elementi come opzioni già pronte, oppure potrebbe fornire solo il primo e lasciare gli altri sette da costruire a chi la usa. Entrambi i casi vengono onestamente descritti come “avere l’autenticazione” in una trattativa commerciale. Solo uno dei due è pronto per la produzione.
Perché i generatori IA costruiscono la pagina di accesso e saltano il resto
I generatori di codice IA sono eccellenti nel costruire esattamente ciò che un prompt descrive, e un prompt raramente descrive il recupero della password. Gli strumenti ottimizzano per il percorso ideale: una schermata di accesso pulita e una dashboard funzionante, perché è ciò di cui ha bisogno una demo e ciò che chi costruisce ha chiesto esplicitamente. Reimpostazione della password, verifica OTP, restrizioni di dominio e scadenza della sessione sono flussi secondari a cui nessuno ha pensato di chiedere, quindi vengono saltati per impostazione predefinita.
La lacuna è invisibile durante la costruzione. L’app funziona, l’accesso funziona, la demo sembra completa. Diventa visibile la prima volta che un utente reale dimentica la password e non esiste una pagina di recupero, o la prima volta che la sessione di un ex dipendente avrebbe dovuto scadere e non lo ha fatto. A quel punto chi ha costruito l’app non sta più consegnando una funzionalità; sta facendo debug e programmando sotto pressione una logica sensibile di reimpostazione della password, spendendo prompt e credit esattamente sul flusso che avrebbe dovuto essere fornito già pronto. Si tratta di uno schema documentato e riconosciuto in tutto il settore, non di un argomento specifico di Softr: la ricerca sulle modalità di fallimento del vibe coding indica “autenticazione fragile e flussi di utilità dimenticati” come uno dei modi standard in cui le app generate dall’IA falliscono in produzione.
- Schermata di login creata
- La schermata di login funziona
- Dashboard funzionante creata
- La dashboard operativa funziona
- Manca il reset della password
- L'utente dimentica la password, manca la pagina di recupero
- Scadenza sessione non gestita
- La sessione di un ex dipendente non scade mai
- Verifica OTP saltata
- Debugging dell'auth sotto pressione
Cosa misura davvero questo criterio in una scheda di valutazione
Sicurezza e controllo degli accessi su questo sito non è un semplice sì/no su “se c’è l’accesso”. Valuta quanta parte di quell’insieme di otto elementi viene fornita già pronta rispetto a quanto l’acquirente deve programmare o configurare da zero, e quanto è granulare il controllo degli accessi risultante una volta che gli utenti reali sono nel sistema.
L’intervallo tra le piattaforme valutate su questo sito è ampio. Softr ottiene 8,5, perché l’accesso con password, OTP, link magico e Google viene fornito come opzioni già pronte, i gruppi di utenti portano restrizioni a livello di riga fino ai singoli pulsanti, e solo l’SSO è riservato al piano Custom enterprise. Retool ottiene 7,5, forte sull’SSO orientato all’uso interno e sui log di audit, ma la sua scheda segnala che non ci sono flussi integrati di accesso, registrazione o reimpostazione della password per gli utenti esterni; questi vengono programmati su misura. Bubble ottiene 6,5 grazie a regole di privacy lato server potenti una volta configurate, ma la configurazione è interamente a carico di chi costruisce, e una regola dimenticata fallisce silenziosamente. Più in basso, Lovable e Bolt ottengono entrambi 3,5, perché la loro sicurezza dipende dal codice generato e dalle regole del database che chi costruisce deve scrivere e verificare da solo, senza alcun modo visivo per controllare cosa è effettivamente esposto.
Questo intervallo è il punto centrale di questa guida. “Avere l’autenticazione” non dice quasi nulla su dove si colloca una piattaforma su questa scala.
La checklist di valutazione
Prima di impegnarvi con una piattaforma, verificate questi punti in ordine:
- Elencate quali degli otto flussi sono già pronti, non solo “supportati”. Chiedete specificamente: la reimpostazione della password è una pagina che esiste già oggi, o una funzionalità che configurerete in seguito con codice su misura? La differenza tra “nativo” e “possibile con lavoro di sviluppo” è la differenza tra un’opzione già pronta e un progetto.
- Verificate quale livello di piano limita l’SSO e i controlli di accesso avanzati. L’SSO in particolare è regolarmente una funzionalità di livello enterprise in questo mercato. Il piano Custom di Softr, il livello Enterprise di Retool e piani superiori con nomi simili altrove lo riservano tutti, quindi la piattaforma che “ha l’SSO” sulla pagina di marketing potrebbe non averlo nel piano che potete effettivamente permettervi.
- Confermate se il controllo degli accessi arriva sotto il livello di pagina. L’accesso basato sui ruoli è il minimo indispensabile. Ciò che decide la sicurezza reale è se le restrizioni raggiungono singoli record, campi e pulsanti, oppure si fermano a “connesso o non connesso”.
- Testate direttamente la gestione delle sessioni. Accedete, poi verificate se potete forzare la scadenza di una sessione, vedere chi è attualmente connesso e controllare la durata della sessione. I portali clienti con turnover di utenti esterni ne hanno bisogno; uno strumento interno per due persone forse no.
- Adattate la risposta alla classe di app, non all’elenco di funzionalità più favorevole della piattaforma.
Perché la risposta dipende da chi accede
Il livello giusto di autenticazione non è fisso; dipende da chi userà l’app.
| Classe di app | Chi accede | Cosa conta davvero |
|---|---|---|
| Strumento interno, 8 colleghi | Account che create e controllate voi | Un accesso di base con controlli sui ruoli spesso basta; potete reimpostare a mano una password dimenticata |
| Portale clienti, centinaia di utenti esterni | Account che non potete gestire uno per uno | Reimpostazione della password in autoservizio, restrizioni di dominio o invito e controlli di sessione non sono più opzionali |
Uno strumento interno per 8 persone può funzionare con l’accesso tramite password e una netta separazione dei ruoli, perché ogni titolare di account è qualcuno che potete aiutare di persona. Un portale clienti che serve centinaia di utenti esterni non può funzionare così. Il recupero in autoservizio smette di essere un extra nel momento in cui non potete più reimpostare personalmente ogni password dimenticata, e la registrazione con restrizione di dominio o solo su invito diventa l’unico modo realistico per impedire che un’app pubblica accumuli account non autorizzati. Valutare la stessa piattaforma per entrambi i casi d’uso senza adattare questo criterio è l’errore di valutazione più comune tra gli acquirenti.
Comprate per l’app che state davvero costruendo
La soluzione non è “esigere sempre tutti i flussi”. È definire onestamente la base di utenti della vostra app prima di scegliere. Una manciata di colleghi fidati può bastare con meno. Centinaia di clienti esterni non possono, e le piattaforme che per impostazione predefinita saltano reimpostazione della password, OTP e restrizione di dominio faranno emergere questa lacuna esattamente quando sarà più costoso risolverla, una volta che esistono già account reali. Valutate la piattaforma in base ai flussi di cui avranno bisogno i vostri utenti reali, usando l’analisi completa su /methodology, e consultate Bubble vs Softr e le migliori piattaforme per portali clienti per vedere come si applica questo concetto a una specifica classe di app.