Perché non dovresti costruire il tuo sistema di autenticazione: lezioni da decine di interviste ai clienti
Puoi costruire il tuo sistema di autenticazione in un giorno, e funziona per anni. Il vero costo appare dopo, il giorno in cui il tuo business cambia. Lezioni da decine di interviste B2B.
YijunDeveloper
Smetti di sprecare settimane sull'autenticazione degli utenti
Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.
L'autenticazione sembra qualcosa che puoi realizzare da solo. Email, password, la codifichi, la confronti al login. Quanto potrà mai essere difficile costruire il tuo sistema di autenticazione?
Puoi farlo. Questa è la trappola.
Abbiamo parlato con decine di team sull'auth che si sono costruiti in casa. La maggior parte è venuta da noi per la stessa ragione: stava rallentando il business.
Settori diversi, stack e dimensioni differenti, ma stesso finale. L'auth costruito era diventato un debito che il team si portava dietro.
La cosa strana è che non si presenta mai come un blackout. Il sistema fa login e funziona bene, fino a che un cambiamento di business blocca la strada: una revisione di sicurezza, il primo cliente enterprise, un'acquisizione, una funzionalità che coinvolge due prodotti.
La settimana scorsa era "tutto a posto". Poi il prossimo elemento nella roadmap resta fermo a causa sua.
Il più grande errore con l'auth in casa è trattarlo come una funzionalità. Puoi scriverlo al giorno uno. Ma una volta che il traffico reale lo attraversa, si intreccia con i tuoi utenti, le organizzazioni e le autorizzazioni.
L'autenticazione non è una funzionalità. È infrastruttura d'identità.
Dietro la pagina di login c'è tutto un modello di identità#
Ogni sistema di auth fatto in casa inizia allo stesso modo. Prendi un'email e una password, la codifichi, la memorizzi, la confronti al login. Quaranta righe di codice, pulito e finito.
I problemi iniziano dopo il lancio. I bot martellano l'endpoint di signup, quindi aggiungi il rate limiting, un CAPTCHA, il fingerprinting dei device. Gli SMS smettono di uscire una mattina, quindi aggiungi i retry e un limite giornaliero. Poi arrivano le parti difficili: reset password sicuro, MFA e il suo flusso di recupero, sessioni e refresh token, e un modello di permessi che è molto più di un semplice booleano is_admin.
Nessuna di queste cose è difficile da sola. Ognuna si inserisce in uno sprint. Ma ogni volta che ne realizzi una, stai rispondendo a una domanda più grande per conto del prodotto.
Sommando queste risposte ottieni il modello d'identità che il tuo prodotto ora assume silenziosamente essere vero: chi conta come utente, se una persona può appartenere a più organizzazioni, come il sistema di identità di un cliente enterprise si integra, e come viene revocato l'accesso quando qualcuno se ne va.
Ogni funzionalità che scrivi dopo dà quelle risposte per scontate, e più tempo passa, più è difficile cambiarle.
Abbiamo visto questa situazione in un'azienda: una SaaS verticale B2B, vent'anni di attività, al servizio di operatori tradizionali. Hanno costruito il proprio auth più di dieci anni fa, con login separato per cliente e controlli di permesso scritti direttamente nei moduli di business. All'epoca era una scelta ragionevole.
Vent'anni dopo, volevano qualcosa che sembra piccolo: una pagina di login unificata, con l'email come username. Non era affatto solo un cambio pagina. Quei controlli si erano diffusi in centinaia di moduli, e unificare il login significava toccare il modello utente, il modello organizzativo, la migrazione delle credenziali e ogni confine di permesso. Nessuno voleva prendersi la responsabilità di firmare tutto, così la questione si è trascinata per anni.
Quando hanno scritto quella prima pagina di login, sembrava una feature. Quello che hanno lasciato era un intero modello identitario.
Quando il business cresce, l'auth in casa smette di bastare#
A onor del vero, l'auth fatto in casa di solito funziona a lungo. Fa login, aggiorna sessioni, serve il business ogni giorno per anni. La sua complessità cresce lentamente, mai tutta insieme, e la gestisci poco alla volta pensando di avere tutto sotto controllo.
Ma restare "abbastanza" spesso significa solo che il business non ha ancora incontrato il muro. Quando lo fa, di solito il problema non è l'auth in sé. È l'attività a fianco che cambia, e "abbastanza" diventa "di ostacolo" da un giorno all'altro.
Le situazioni che seguono si presentano per la maggior parte dei prodotti quando scalano. Sembrano diverse, ma in realtà sono la stessa cosa: il business è andato avanti, e il vecchio modello identitario non riesce a stargli dietro.
Lo scenario: un cliente vuole loggarsi col proprio IdP, e il tuo sistema auth non ha alcun concetto di "identity provider esterno."
Arriva il primo vero contratto enterprise, e la loro procurement ti manda un documento con i requisiti. Prima SSO con Microsoft Entra o Google Workspace. Poi sia SAML che OIDC, perché il prossimo cliente usa altro. Poi SCIM, per aggiungere e rimuovere dipendenti in automatico.
Ogni cliente ha la sua configurazione: diversi protocolli, mappature dei campi, rotazioni di certificati, e modi diversi di mappare la struttura della loro organizzazione sulla tua.
E quasi niente di questo lavoro si ricicla. Il cliente dopo usa un altro IdP e una nuova configurazione, e quasi si ricomincia da capo. Il SSO non è una funzionalità che costruisci una volta. Ogni cliente importante che firmi va rifatto, e il costo cresce con il numero di clienti.
L'auth non è più "permetti agli utenti di accedere al tuo prodotto." È "fai sì che il tuo prodotto si integri col sistema di identità del cliente." Due lavori completamente diversi.
Abbiamo visto un'azienda in cui l'intera configurazione SSO era fatta a mano, e solo un ingegnere la conosceva da cima a fondo. Quando lui era presente, i clienti andavano live. Quando era in ferie, sales e onboarding si fermavano in coda ad aspettare che tornasse. Quando ha lasciato, tutta la conoscenza è uscita con lui.
Niente di tutto questo era sul tavolo il giorno in cui hanno deciso di costruire la propria autenticazione.
Lo scenario: i tuoi dati identitari sono partiti frammentati, divisi per organizzazione e prodotto, e man mano che l'azienda cresce hai bisogno di un'identità unificata.
La stessa azienda ventennale di prima ha incontrato questo bisogno quando ha tentato di unificare il login, e la stessa dinamica si vede in diversi prodotti. Abbiamo collaborato con una piattaforma con nove prodotti, tutti acquisiti, ognuno con la propria autenticazione e archivio utenti.
Un'acquisizione non li fonde per te. Ogni prodotto che compri ti porti dietro un altro stack auth, e nove in parallelo richiedono personale solo per la manutenzione.
Le domande si accumulano. La stessa persona è un utente solo in A e B o due? Come fai a mappare lo stesso cliente in entrambi? Come autorizzi una funzionalità cross-prodotto? Quando un dipendente lascia, come revochi l'accesso a tutti e nove insieme? E dove controlli il log di tutto ciò?
Nessuno dei nove è rotto. Insieme, sono un muro.
"Unificare l'identità" sembra una feature. Nel codice significa ridefinire la cosa più fondamentale che c'è: cosa conta come un utente e un'organizzazione. Quasi ogni feature dipende dalla vecchia definizione, quindi cambiarla sposta l'intero strato superiore.
Nell'era AI, agenti e CLI accedono al sistema per conto dell'utente#
Lo scenario: non sono più solo persone a loggarsi da browser. Ora agenti, comandi CLI e script agiscono per conto di un utente, mentre il tuo auth sa solo gestire chi accede da una pagina.
Un agente deve chiamare i tuoi strumenti interni per un utente. Un server MCP deve esporre risorse protette. Una CLI deve accedere ai dati di account senza browser.
Tutti e tre sollevano le stesse domande: per quale utente agisce la richiesta, quali risorse può toccare, a chi è rilasciato il token, qual è il suo scope, come lo revochi, registri l'agente o l'utente?
Il vecchio sistema non ha mai costruito i meccanismi che servono a questi client. MCP si basa su OAuth per l'autorizzazione. Una CLI passa o da login OAuth, oppure utilizza un token di accesso personale che rappresenta una persona e può essere revocato in qualsiasi momento. Niente di ciò era pensato per una pagina di login.
Se il tuo auth è stato disegnato solo per login di persone da una pagina, ora devi gestire un client che si presenta ad agire per quella persona.
La manutenzione a lungo termine è il costo più alto dell'auth in casa#
Nessuna delle situazioni sopra è "auth crashata." Il sistema gira. Sembra una piccola feature, ma appena inizi, diventa strategia prodotto, migrazione dati e delivery per il cliente.
Il caso più chiaro è l'MFA. In superficie è "possiamo verificare ancora una volta dopo il login?"
Due passi dopo è: su quali org e utenti la forzi, un admin può imporla ai membri, le azioni sensibili come cambiare dati di pagamento richiedono un check ulteriore, come generi e resetti i codici di recupero, può farlo il supporto, l'MFA di un utente SSO è gestita da te o dall'IdP cliente? Aggiungere MFA significa mettere tutto un nuovo strato di policy di sicurezza.
"Sincronizza solo alcuni utenti" è la stessa storia: dietro ci sono una serie di decisioni su onboarding, offboarding, membri di più organizzazioni, ognuna che assume che il modello utente/org sia nato giusto.
Più feature aggiungi, più mantieni un prodotto di identità all'interno del tuo prodotto. La prima versione è economica, pochi ingegneri, poche settimane. Ma continuerai a nutrirlo anno dopo anno.
Il costo nascosto: la fattura è cambiata solo nel modo in cui la paghi#
La ragione più comune per costruirsi l'auth da soli è il costo, e non è ingenua.
Un'organizzazione di membership che abbiamo intervistato ha fatto i conti cinque anni fa. Avevano circa centomila membri, ma solo pochi migliaia loggati regolarmente. I vendor fanno pagare per numero totale di membri, il preventivo sforava di molto il budget e farselo in casa costava meno. Per quell'anno, non era una scelta sbagliata.
Cinque anni dopo, la matematica si era ribaltata. Mantenere il proprio login e tenerlo sicuro era già costato di più di quanto sarebbe costato comprarlo.
Nel primo anno, la fattura che eviti è visibile e il tempo di ingegneria no. Dopo cinque anni, la fattura evitata è la stessa cifra, ma il tempo degli ingegneri è diventato ritardi sulla roadmap, debito di sicurezza, e manutenzione che nessuno vuole.
Quindi costruire il tuo auth non è gratis. Semplicemente non riceverai mai una fattura che dice "abbonamento autenticazione." Paghi in mesi persona, scadenze mancate, rework, debito di sicurezza e attenzione sottratta al prodotto principale.
Quel tecnico che gestisce l'SSO a mano non è un caso isolato. Con auth in casa a lungo, il contesto critico finisce su una o due persone: quale cliente è configurato come, quale campo non va toccato, perché una migrazione passata è stata fatta in un certo modo. Raramente va nei documenti. Vive nella testa di qualcuno.
Quando c'è, la delivery avanza. Quando manca, il flusso enterprise si ferma, e scopri che la tua infrastruttura più importante non ha proprietari, solo "chi sa come funziona."
Alcuni team vanno oltre e costruiscono una piattaforma self-service SSO per i clienti. Sembra maturo, finché chiedi quanti clienti la usano. Abbiamo visto una con 1,5 milioni di attivi al mese con un intero sistema di questo tipo per appena una dozzina di clienti.
Pensavi di aver fatto una feature. Avevi costruito un prodotto interno, con il costo spalmato su una dozzina di clienti. Se l'identità è il tuo business, ne vale la pena. Se no, è il costo nascosto allo stato puro.
Torniamo al SaaS verticale dei vent'anni. Non sono ingegneri deboli. Tenere in vita per vent'anni un prodotto del settore dimostra che conoscono molto bene i propri clienti.
Questo è il problema. Detto brutalmente: vuoi che passino le giornate a gestire SSO per ogni client e tirare fuori la logica dei permessi da centinaia di moduli, o che si concentrino ancora di più sul software di settore stesso?
Non è perfezionismo ingegneristico. È allocazione di risorse. Se costruisci bill pay, SaaS verticale, portali per membri, software di operations, nessun cliente ti paga un centesimo in più perché hai scritto il tuo server OAuth interno.
Un team bill-pay che abbiamo intervistato l'ha detto chiaro: il loro IdP in casa andava, ma è una scelta strategica. Meglio scrivere poco codice per auth. Risparmia energia per rendere il core business il migliore possibile, e usa il sistema auth più rodato per il resto.
Auth deve essere affidabile. Ma "affidabile" non significa "fatto da te." Il tuo database, la consegna email, il cloud devono essere affidabili, e un team esperto non assume mai che qualcosa debba essere interno solo perché è critico.
Per la maggior parte dei prodotti, auth è una dipendenza, non un differenziatore. Salvo che tu non faccia identità di mestiere, mantenere un prodotto di identità dentro il tuo prodotto non è un vantaggio. È un drenaggio continuo di risorse.
È facile cadere nell'estremo: mai scrivere auth. Anche questo è sbagliato.
In alcune fasi, farselo da sé (o a metà) ha perfettamente senso: demo interni, primissimi prototipi, esperimenti one-off di validazione. E se il tuo prodotto ha autorizzazioni particolari che le piattaforme esterne non esprimono, tenersi quella parte in casa, facendo gestire all'esterno autenticazione, sessioni, SSO, MFA e directory utenti, va più che bene.
Attento solo alla china dei proof of concept. Abbiamo visto spesso lo stesso percorso: due sviluppatori passano sei-otto mesi su un prototipo di integrazione con un sistema esterno. L'approccio non era sbagliato. Secondo loro, usciva buono. Semplicemente, non doveva mai scalare davvero.
E un POC è la cosa più facile da cristallizzare in architettura. Sei mesi dopo è "la soluzione attuale", due anni dopo "il sistema legacy", cinque anni dopo "infrastruttura che non si può toccare". Il miglior momento per mollare l'auth in casa non è dopo che si rompe. È prima che diventi fondamento.
Quindi la linea è questa: il punto non è se hai scritto una riga di auth, ma se hai preso in carico un pezzo generico di infrastruttura per l'identità e lo tieni in casa sui tuoi team a tempo indeterminato.
Realizza da sé solo le capability d'angolo. Stai attento al core dell'identità. E senza accorgertene, evita di costruirti una piattaforma CIAM completa.
Se non la costruisci tu, come scegliere una soluzione auth?#
Se decidi di non scriverla tu, la prossima domanda è: di chi la compri, e come scegli?
La maggior parte delle soluzioni mature copre già le feature: SSO, MFA, organizzazioni multiple, login unificato, accesso agenti. Quindi la vera differenza non è quasi mai nelle feature.
Quello che è più facile trascurare, e su cui vale la pena comparare, sono questi punti. Sono sfaccettature di un unico tema: non uscire da qualche migliaio di righe tue solo per rientrare prigioniero di un sistema da cui non puoi uscire.
Scegli protocolli standard, non stack inventati dal vendor. OIDC, OAuth, JWT firmati RS256 sono cose che già conosci. Leggi i claim dal token, senza doverti imparare l'API specifica.
Tieni sempre una porta aperta. Se la soluzione è open-source e self-hostable, puoi uscire quando vuoi. (Manternerne una versione self-hosted nel tempo ha naturalmente i suoi costi nascosti.)
Non lasciare che la fatturazione segua la tua tabella utenti. Fatturare su utenti registrati o attivi al mese segue una tabella che cresce sempre, piena di gente che non torna, e su larga scala diventa una "growth tax". Questo è il prezzo che ha spinto il membership org qui sopra a costruire l'auth in casa.
I tuoi dati non sono bloccati. Puoi esportare gli utenti quando vuoi. E affidare questi dati sensibili a un host specializzato ti evita il rischio di dover custodire dati privati che non dovresti detenere.
Disclosure: Logto è il prodotto auth che abbiamo costruito proprio secondo questi quattro principi. È open source, self-hostable, e anche offerto in Cloud gestito: usa Cloud senza manutenzione, oppure self-hosta l'open-source per il massimo controllo, e se vuoi cambiare, la porta è aperta.
Sign-in, MFA, SSO e RBAC funzionano subito su OIDC standard, e la fatturazione segue i token: paghi ciò che usi.
Ci sono altre opzioni mature, e auth non ha mai avuto una sola risposta giusta. Se valuti, ho scritto un articolo su come scegliere una soluzione auth che puoi leggere.
Conclusione: non confondere una piattaforma di identità di lungo termine con una feature ordinaria#
Farsi l'auth da soli di solito ha senso il giorno uno. Il punto è che nel tempo diventa infrastruttura.
Ogni passo avanti del business lo mette in discussione: gli enterprise vogliono SSO, la sicurezza vuole MFA, il prodotto vuole login unificato, più prodotti vanno collegati, agenti AI vogliono accedere alle risorse per l'utente. Dietro ogni feature apparentemente piccola si nasconde una serie di politiche, e anno dopo anno ci spendi il tempo di sviluppo che serviva al core product.
Questa fattura non arriva mai il primo giorno. Di solito arriva anni dopo. In quel momento lo vedi: quella pagina di login che hai scritto all'inizio era già infrastruttura d'identità che avrebbe regnato su tutto il ciclo di vita del prodotto.
Probabilmente auth non è il tuo vero business. Prima lo capisci, prima puoi portare tempo, energie e risorse là dove servono davvero.
Dovresti mai costruire il tuo sistema di autenticazione?#
No. Demo all'inizio, strumenti interni, progetti sperimentali, o necessità di autorizzazioni super granulari che le piattaforme pronte non esprimono sono casi in cui può avere senso. Da evitare è prendersi in carico una parte generica di infrastruttura identitaria a lungo termine, senza accorgersene, e lasciarla dentro la manutenzione del team prodotto.
Qual è la differenza tra autenticazione e autorizzazione?#
L'autenticazione risponde a "chi sei". L'autorizzazione risponde a "cosa puoi fare". In una SaaS reale sono difficili da dividere: utenti, organizzazioni, ruoli, permessi, sessioni, claim dei token e audit log si intrecciano. Quando cambi un sistema auth, non puoi guardare solo la pagina di login.
Perché significa far sì che il tuo prodotto si colleghi al sistema di identità del cliente. Ogni cliente usa IdP, protocolli, campi claim, certificati e mapping organizzativi diversi. Collegare il primo non rende automatici gli altri. Spesso, diventa lavoro manuale che capisce un solo ingegnere.
Abbiamo gestito il nostro auth per anni. Possiamo ancora migrare?#
Sì, anche se di solito non conviene fare un cutover immediato. Migra a strati: metti subito signup e login nuovi, più SSO enterprise, sulla nuova piattaforma d'identità, e migra gli utenti da sistemi precedenti al prossimo login. Tieni rollback e audit, così la migrazione non è mai irreversibile.
