Auth per persone che conosci già

La quasi totalità dei sistemi di autenticazione che costruiamo è progettata per gli sconosciuti.

Non ci pensiamo in questi termini, ma è così. Quando costruisci una form di registrazione, stai assumendo che dall'altra parte ci sia qualcuno che non conosci, di cui non ti fidi a priori, che potrebbe essere chiunque. Da questa assunzione discendono registrazione pubblica, verifica email, password reset, account recovery, rate limiting su tutto. È un'infrastruttura progettata per difendersi da qualcuno che non hai invitato.

Per ReD Sposi questa assunzione era falsa dall'inizio.

Il problema al contrario

Gli invitati al matrimonio sono circa cento persone. Li conosco tutti per nome. Molti di loro non sono particolarmente tecnici — ci sono nonni, parenti lontani, amici che usano lo smartphone principalmente per WhatsApp. Nessuno di loro avrebbe dovuto registrarsi, scegliersi una password, confermare un'email, e poi ritrovare quella password quattro mesi dopo quando si siede al tavolo e vuole caricare una foto.

Il problema di autenticazione che avevo davanti era il contrario di quello standard:

• L'insieme degli utenti è chiuso e noto in anticipo
• Nessuno si deve autoregistrare
• L'identità è già stabilita fuori dal sistema (la lista degli invitati)
• L'accesso deve essere semplice da recuperare, non da proteggere

In questo contesto, email e password non risolvono nulla. Aggiungono solo superfici di attrito.

Il codice invito come identità

La soluzione era già nella metafora del matrimonio: l'invito.

Ogni invitato riceve un codice — sei caratteri alfanumerici, generati dall'admin, associati a un nome. Il codice è l'identità. Non c'è nient'altro da sapere su di te finché non entri nell'app e completi l'RSVP.

POST /api/auth/login
{ "code": "ABCD12" }

→ { token: "eyJ..." }

Nessuna email. Nessuna password. Nessuna verifica. Se hai il codice, sei dentro.

Il JWT generato ha una scadenza lunga — mesi, non ore — perché il caso d'uso non prevede rotazione frequente. Un invitato apre l'app ogni tanto per settimane, poi la usa intensamente il giorno del matrimonio. Non ha senso fargli fare re-login nel mezzo della cerimonia.

Cosa gestisce l'admin

Il pannello admin è dove l'utente veramente privilegiato — io — controlla tutto.

Ogni invitato è un documento in MongoDB con nome, codice, e una struttura che si popola man mano: preferenze sul menù, intolleranze, richiesta navetta, RSVP completato. L'admin può creare codici, rigenerarli, disattivarli, vedere chi ha fatto login e chi no.

Questa asimmetria è deliberata. Il "sistema di registrazione" di ReD Sposi non è una form pubblica — è io che creo un documento. Non ho costruito auth per gli sconosciuti; ho costruito uno strumento di gestione per una lista che esiste già su carta.

Gli edge case del mondo reale

Progettare per persone conosciute sposta gli edge case.

Il codice viene perso. È il caso più comune. La soluzione non è un flusso di recovery — è una telefonata. O un messaggio su WhatsApp. O un accesso al pannello admin da parte mia. Non ho costruito self-service recovery perché non serviva: sono sempre raggiungibile e l'insieme di persone è piccolo.

Il codice viene condiviso. Una coppia usa lo stesso codice dal telefono di uno solo. È successo. Dal punto di vista tecnico, entrambi risultano lo stesso invitato. Nella pratica, per un matrimonio va bene: l'RSVP è per coppia, non per individuo. Se avessi avuto bisogno di granularità per persona, avrei generato due codici separati. Il design del sistema lo permette senza modifiche.

Qualcuno vuole aggiungere un accompagnatore. Questo è l'unico caso che richiede un'azione reale. Creo un nuovo documento, genero un nuovo codice, lo mando. Cinque minuti. Non ho costruito un flusso di "invita un amico" perché gestire la lista degli invitati è un problema umano, non un problema tecnico.

La lezione più grande

C'è un riflesso professionale comune: quando si deve fare auth, si parte dalla libreria di turno, si implementa la registrazione, si aggiunge il reset della password, si configurano i token di refresh. È una checklist che abbiamo eseguito tante volte da averla automatizzata.

Il problema è che quella checklist è scritta per un caso d'uso specifico — e quel caso d'uso non è il tuo.

Per ReD Sposi la domanda giusta non era "come faccio l'auth?" ma "chi sono i miei utenti e qual è il loro rapporto con il sistema?". La risposta a quella domanda — persone conosciute, insieme finito, accesso semplice sopra ogni altra cosa — rendeva inutile il novantacinque percento dell'infrastruttura standard.

Riconoscere quando non stai costruendo per gli sconosciuti è una competenza sottovalutata. La maggior parte degli strumenti che usiamo assume il caso più difficile. Spesso il tuo caso è molto più semplice — e la cosa più intelligente che puoi fare è non fingere che non lo sia.