Puoi costruire l’autenticazione in un giorno. Questa è la trappola.

Decine di team B2B ci hanno raccontato la stessa storia. Tutto parte da una semplice pagina di login. Poi il traffico reale la attraversa e, in silenzio, diventa infrastruttura identitaria: la base su cui poggia tutto il tuo prodotto.

Inizia gratis con Logto

Parla con il nostro team

Sembrava una funzione. Ha lasciato dietro di sé un intero modello d’identità.

Ogni autenticazione costruita in casa parte da poche righe di codice. I problemi iniziano dopo il lancio, quando ogni piccola decisione diventa silenziosamente il modello che tutto il tuo prodotto dà per scontato.

Giorno uno: quaranta righe di codice

Email, password, criptala, salvala, confronta al login. Pulito e fatto.

Ecco perché ogni team comincia da qui, e perché l’autenticazione sembra una cosa risolvibile in un pomeriggio.

Giorno duecento: un modello d’identità nascosto

Chi è considerato utente. A quale organizzazione appartiene. Quale sessione è ancora affidabile. Come viene revocato l’accesso.

Limiti di richiesta, MFA e relativo processo di recupero, sessioni, refresh token, modello organizzativo che va oltre un semplice booleano is_admin. Ogni risposta che implementi diventa una regola che il prodotto ora dà per sottintesa.

Anno cinque: una base che non puoi più toccare

Cambiare la pagina di login su carta voleva dire rifare dalle fondamenta l’identità nel codice.

Una SaaS ventennale ha tentato di passare a email come username. I controlli dei permessi erano sparsi in centinaia di moduli. Nessuno voleva approvare, così si è trascinata finché non è stato più possibile.

L’autenticazione interna funziona benissimo — finché l’azienda non cambia

Fa accedere le persone per anni senza incidenti. Poi un cambiamento di business trasforma all’improvviso "abbastanza" in "un ostacolo". Questi tre arrivano per quasi ogni prodotto che scala.

I clienti enterprise iniziano a chiedere la SSO

Il primo grosso contratto arriva e il procurement vuole SSO tramite il suo Entra o Google Workspace. Poi sia SAML che OIDC, perché il cliente successivo usa altro. L’implementazione di identità è diversa per ogni cliente, e quasi nulla del lavoro si può riutilizzare.

Protocolli diversi, mappature di campi e rotazioni dei certificati per ogni cliente
La SSO non si costruisce una volta. La ricostruisci per ogni azienda con cui firmi
Diventa in silenzio attività manuale che solo un ingegnere conosce da cima a fondo

Scopri di più

L’identità, da frammentata, ora deve essere unica

Divisa per organizzazione, per prodotto, spesso ereditata da acquisizioni. “Unificare l’identità” sembra una funzione; nel codice vuol dire ridefinire cosa è un utente e cosa è un’organizzazione.

Un’email può appartenere a più organizzazioni? Come migri i vecchi nomi utente?
Nove prodotti da acquisizioni significano nove stack di autenticazione che girano in parallelo
Revoca un utente uscente da tutti in una volta e controlla tutto da un unico punto

Scopri di più

Agenti AI e CLI iniziano ad agire per conto dell’utente

Non si tratta più solo di persone in un browser. Agenti, server MCP e riga di comando rivendicano tutti di agire per qualche utente. Ma la tua autenticazione sa solo come far accedere una persona via pagina web.

A chi è rilasciato il token, con quali permessi e per quale pubblico?
Concedi l’accesso solo a uno strumento o a una fetta di dati, poi revocalo dopo
L’accesso MCP e CLI si basa su OAuth, non su un modulo di login

Scopri di più

Il vero costo non è costruirlo. È mantenerlo per anni.

La prima versione costa poco: pochi ingegneri, poche settimane, pronto. Ma poi ogni anno ci riversi tempo degli ingegneri che serviva per il tuo core business.

Il conto è cambiato, non sparito

Non ricevi mai una fattura con scritto “autenticazione”.

Paghi in mesi/persona, scadenze mancate, debito di sicurezza e rielaborazione. Un’associazione ha implementato la propria soluzione per evitare la licenza; dopo cinque anni, mantenerla è costato più che comprare.

Tutto si regge su una o due persone

Il contesto critico sta nella testa di qualcuno, non nei documenti.

Come è configurato ogni cliente, perché certe migrazioni sono state fatte in un certo modo. Se quella persona manca, la pipeline enterprise si blocca. Se se ne va, porta tutto con sé.

Dove vuoi far lavorare i tuoi ingegneri?

Nessun cliente ti paga di più perché hai scritto un tuo server OAuth.

L’autenticazione dev’essere affidabile. Ma “affidabile” non significa “scritta da te”. Per la maggior parte dei prodotti è una dipendenza critica, non una caratteristica differenziante. E questa è una bella differenza.

Se non lo costruisci, come scegli?

Le soluzioni mature coprono già le funzioni: SSO, MFA, organizzazioni, login unificato, accesso agenti. La vera differenza è la possibilità di andarsene. Non passare da un tuo sistema a migliaia di righe per poi trovarti bloccato a casa d’altri.

Protocolli standard, non stack inventati

OIDC, OAuth e JWT firmati RS256 già conosciuti. Leggi direttamente i claim da token standard, senza dover imparare API specifiche di un vendor.

Una porta sempre aperta

Se è open source e installabile in autonomia, puoi andare via quando vuoi. Non scambiare il tuo sistema personalizzato per uno ospitato e bloccato altrove.

La fatturazione non segue la tabella utenti

Fatturare per utenti registrati o attivi mensili significa inseguire una tabella che cresce sempre. Alla lunga è una tassa sulla crescita, proprio ciò che spinge i team a reinventare la ruota.

I tuoi dati non saranno mai bloccati

Esporta i dati utenti quando vuoi. Inoltre, affidare questi dati sensibili a uno specialista ti risparmia il rischio di proteggere una montagna di PII che non era compito tuo custodire.

Probabilmente l'autenticazione non è il tuo core business. Trattala così.

Logto è open source, installabile in autonomia e disponibile anche come SaaS Cloud gestito. Login, MFA, SSO e RBAC funzionano subito con OIDC standard. La fatturazione segue i token, e quando vuoi cambiare, la porta resta aperta.

Inizia gratuitamente

Contattaci

Domande frequenti

Non si dovrebbe mai costruire il proprio sistema di autenticazione?

No. Demo rapide, strumenti interni, progetti di validazione una tantum o autorizzazioni molto specifiche che le soluzioni standard non coprono possono essere una buona ragione per costruirsi tutto o in parte la soluzione. Quello da evitare è prendersi sulle spalle un’infrastruttura d’identità generica e di lungo periodo senza rendersene conto, lasciandola poi nella manutenzione di un team di business.

Qual è la differenza tra autenticazione e autorizzazione?

Perché la SSO enterprise complica l’autenticazione interna?

Abbiamo usato la nostra soluzione per anni. Possiamo ancora migrare?

Sì, anche se di solito un taglio netto non è la strada giusta. Il percorso realistico è migrare a strati: inserire primo i nuovi signup, i nuovi login e la SSO enterprise sulla piattaforma d’identità, poi portare gli utenti esistenti gradualmente al loro prossimo login. Unifica prima la directory utenti e il modello organizzativo, poi procedi con permessi granulari nel tempo, mantenendo sempre rollback e audit trail.

Perché agenti AI e MCP stanno diventando una nuova fonte di pressione per l’autenticazione?

Perché aggiungono un nuovo caso: un client che accede alle risorse per conto di un utente. Se il vecchio sistema era stato pensato solo per una persona che fa login su una pagina, fatica a rispondere a chi viene rilasciato il token, a quale scopo, come revocarlo e chi deve essere loggato nei tracciamenti. In fondo, è la stessa classe di cambiamento di business come la SSO enterprise, solo con un trigger più moderno.