Il miglior CIAM self-hosted per chi crea SaaS B2B

Se hai dato un'occhiata ai prezzi di alcune piattaforme CIAM in SaaS, avrai notato quanto tendono a diventare care e con ogni probabilità hai già pensato a una soluzione self-hosted.

Questo articolo parla delle quattro piattaforme CIAM self-hosted che un piccolo team SaaS B2B può davvero gestire senza che diventi un secondo lavoro a tempo pieno: ZITADEL, FusionAuth, Logto e Ory Hydra. Non hanno tutte la stessa forma, e quella giusta per te dipende meno da una lista di funzionalità e più dal tipo di prodotto B2B che stai costruendo. Le ho fatte girare fianco a fianco su un unico VPS per una settimana per preparare questo confronto, e quello che segue è la versione che manderei a un fondatore che mi scrive in DM sul CIAM.

Una precisazione subito: qui si parla di CIAM come funzionalità di prodotto, non di SSO interno per il tuo team.

La versione breve

Quattro piattaforme CIAM self-hosted, una riga ciascuna:

• ZITADEL se vuoi multi-tenancy e organizzazioni B2B pronte all'uso.
• FusionAuth se vuoi un'interfaccia di amministrazione curata e uno storico di release lungo e prevedibile.
• Logto se vuoi l'esperienza da sviluppatore più pulita fin dal primo giorno.
• Ory Hydra se lavori a livello di protocollo e vuoi il motore OAuth 2.0, non un'app di login già impostata.

In sintesi: ZITADEL è la scommessa iniziale più sicura per un tipico SaaS B2B, e il resto dell'articolo sviscera questo ragionamento.

Perché il CIAM è una decisione diversa dal SSO aziendale

Se il SSO del tuo team interno va giù, il danno di solito resta contenuto. I tuoi ingegneri magari perdono l'accesso a Grafana o a un altro strumento interno per un'ora. Se va giù il CIAM, i tuoi clienti paganti non riescono proprio ad accedere al prodotto. La domanda passa così da «quale strumento di autenticazione è comodo per il nostro team?» a «di quale sistema di autenticazione possiamo fidarci come parte del prodotto stesso?»

Il CIAM, il tipo di infrastruttura di identità di cui ha bisogno un SaaS B2B, richiede anche primitive che molti strumenti di SSO aziendale non mettono in primo piano. Il tuo cliente non è un singolo utente: è un'organizzazione (un tenant) con i propri utenti, ruoli, brand e, possibilmente, la propria connessione SAML verso un IdP aziendale. Non stai solo autenticando persone: stai isolando gli utenti di un'azienda da quelli di un'altra all'interno dello stesso prodotto. È questa la forma B2B che i quattro strumenti qui sotto affrontano, ciascuno a modo suo. Keycloak ora ha Organizations di prima classe, quindi liquidarlo come strumento solo per il personale interno sarebbe superato; spiego la sua assenza nelle FAQ.

Anche il triangolo costruire / comprare / self-hosting qui ha un aspetto diverso. Scrivere OAuth da zero è un errore evitabile. Stai rilasciando un prodotto SaaS, non un identity provider. Comprare il gestito (Auth0, Clerk, WorkOS) è la scelta giusta quando il tuo team ha zero capacità ops e un budget sensato. Non direi mai a una startup di due persone di fare self-hosting dell'autenticazione il primo giorno. Il self-hosting diventa razionale quando il prezzo per MAU del CIAM gestito supera il costo dell'infrastruttura più il tempo di engineering ricorrente, oppure quando ti serve controllo diretto su deployment e data plane. Nei team con cui ho lavorato, quel punto arriva di solito tra «abbiamo un prodotto vero» e «abbiamo una vera funzione di customer success».

Se cerchi il SSO per le tue applicazioni invece che per quelle dei tuoi clienti, quello è un confronto diverso da questo. Passiamo alle nostre scelte migliori.

I quattro strumenti, uno per uno

Ho scelto questi quattro perché hanno una forma abbastanza CIAM da poter essere valutati come infrastruttura di prodotto, non solo come SSO interno. ZITADEL, FusionAuth, Logto e Ory offrono tutti un vero percorso self-hosted e abbastanza traction da prenderli sul serio. Le opzioni che sono solo librerie, quelle di SSO aziendale e quelle meno mature stanno meglio nelle FAQ.

ZITADEL

ZITADEL è una piattaforma di identità di origine svizzera scritta in Go, con architettura event-sourced e backend PostgreSQL. Al 27 luglio 2026 la sua ultima release su GitHub è la the 4.16 series, current as of July 2026. ZITADEL è passato da Apache 2.0 a AGPL-3.0 a partire dalla v3; per un uso SaaS normale l'impatto pratico è di solito meno spaventoso di quanto sembri, e ne parlo in dettaglio nelle FAQ.

Ciò che distingue ZITADEL per il SaaS B2B: le organizzazioni e la multi-tenancy sono primitive di prima classe, non funzionalità che componi a partire da oggetti generici. Crei una Organization, che riceve i propri utenti, policy, branding e impostazioni di accesso, e puoi concederle progetti così che i suoi amministratori gestiscano l'assegnazione dei ruoli per i propri utenti. Non devi inventarti il concetto di «tenant» sopra utenti generici. Parti già da lì.

L'esperienza da sviluppatore è API-first, con le attuali API REST di risorse v2 più accesso gRPC e REST ai servizi v1 legacy. SDK ufficiali e della community coprono i principali stack server. La console di amministrazione è funzionale, ma più spartana di quella di FusionAuth.

La mia lettura: Se stai costruendo un SaaS B2B e sai che avrai dei tenant, io partirei da ZITADEL. Tra le opzioni self-hosted è quella modellata più esplicitamente attorno al problema del login B2B.

FusionAuth

FusionAuth è una piattaforma statunitense di Inversoft, LLC (una LLC del Delaware che opera come FusionAuth), sul mercato da più tempo delle altre tre, e si vede, in senso buono. L'interfaccia di amministrazione appare decisamente più progettata delle altre, la documentazione è matura e la cadenza delle release è costante anziché forsennata. Se ti è mai capitato di ereditare un'integrazione di autenticazione vecchia di quattro anni ringraziando in silenzio il collega che aveva scelto l'opzione noiosa, FusionAuth è la versione del CIAM che si merita quel ringraziamento.

È la licenza a far inciampare: FusionAuth Community è gratuito da self-hostare, ma il prodotto principale non è open source. Il prodotto è regolato dalla licenza proprietaria di FusionAuth, e i suoi limiti contano se prevedi di ridistribuire, incorporare, rimarchiare, rivendere o ospitare FusionAuth per i tuoi clienti. La versione Community self-hosted copre il caso centrale del SaaS B2B; i piani a pagamento aggiungono funzionalità come il SAML avviato dall'IdP, la MFA avanzata e i temi specifici per applicazione, mentre SCIM, Tenant Manager e le policy MFA a livello di applicazione stanno in Enterprise.

Sulla forma B2B: FusionAuth modella tenant e applicazioni, ma l'astrazione è «autenticazione containerizzata per tenant» più che «organizzazioni B2B come oggetto di dominio». Funziona (ci ho rilasciato prodotti sopra), ma la multi-tenancy sembra più una primitiva di isolamento che un modello B2B di prima classe. Gli SDK ufficiali e le librerie client sono numerosi:

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

Le librerie lato server sono client API leggeri. La console di amministrazione è comparativamente più facile da affidare a una persona ops non ingegnere rispetto alle altre.

La mia lettura: Se il tuo team dà più valore alla cura dell'interfaccia e a uno storico lungo e prevedibile che alle primitive native B2B, allora FusionAuth. È la scelta più «noiosa» qui, e questo è un complimento.

Logto

Logto è il più recente dei quattro, sviluppato da Silverhand Inc. e con licenza MPL-2.0, ed è quello a cui la dashboard sta più evidentemente a cuore. Il setup del primo giorno è relativamente rapido. Fai il provisioning, passi dal wizard e in una quindicina di minuti hai un provider OIDC funzionante con una UI di login predefinita dignitosa (l'ho cronometrato la settimana in cui ho fatto girare i quattro fianco a fianco). Le sue quick start ufficiali coprono framework e stack server moderni, quindi se il tuo stack è «Next.js + Postgres + qualcosa» ti sentirai a casa.

La sua risposta B2B si chiama Logto Organizations. Copre le primitive B2B fondamentali: appartenenza all'organizzazione, ruoli con ambito organizzativo, inviti ai membri, provisioning just-in-time e integrazione SSO enterprise. Il modello di organizzazione è più recente di quello di ZITADEL, quindi testerei qualsiasi flusso SAML, SCIM o di federazione insolito con i tuoi clienti target prima di impegnarti.

Il compromesso è la maturità: Logto è l'opzione più recente qui. La roadmap corre veloce, il che è ottimo quando arriva una funzionalità che ti serve e scomodo quando arriva un breaking change. Se il tuo SaaS B2B sta sul lato semplice dello spettro multi-tenant (poche organizzazioni e nessun requisito di federazione esotico), l'esperienza da sviluppatore di Logto rende più facile il resto della decisione.

La mia lettura: Se vuoi il primo giorno più veloce e le tue esigenze B2B sono ancora relativamente semplici, allora Logto.

Ory Hydra (e lo stack Ory)

Ory Hydra è il server OAuth 2.0 / OpenID Connect dell'ecosistema Ory, con licenza Apache-2.0. Lo stack Ory completo affianca Hydra a Ory Kratos (identità e gestione utenti, login self-service, registrazione, MFA e recupero account), Ory Keto (un server di autorizzazione in stile Zanzibar che fa da policy decision point) e Ory Oathkeeper (un proxy di identità e accesso che autentica, autorizza e modifica le richieste HTTP in ingresso). Assembli ciò che ti serve. È tutto scritto in Go e le API sono pulite.

Il punto (e non è un difetto: per il team giusto è un pregio) è che Hydra è il motore, non l'applicazione. Per progetto, Hydra si collega a un'app separata di login e consenso che fornisci tu. Se vuoi una schermata di login pronta all'uso, non è lo strumento giusto. Se stai costruendo qualcosa in cui il flusso di autenticazione fa parte del prodotto (una piattaforma per sviluppatori, un portale B2B su misura o un prodotto API-first con onboarding personalizzato), l'assenza di una UI imposta è esattamente ciò che vuoi.

La storia B2B è componibile anziché chiavi in mano. Puoi modellare la multi-tenancy collegando schemi Kratos e relazioni Keto al tuo livello di organizzazione, e funziona, ma il cablaggio lo fai tu. Il costo è più idraulica; il beneficio è il controllo sull'esperienza. La documentazione di Ory copre in profondità la superficie del protocollo, ma il modello componibile presuppone che tu sia a tuo agio nel prendere decisioni a livello di protocollo. Se «audience claim» o «PKCE» non ti dicono nulla, parti da uno degli altri tre.

La mia lettura: Se stai costruendo qualcosa a livello di protocollo (gateway di autenticazione, flussi su misura, piattaforma per sviluppatori) e le app standard ti sembrano limitanti, Ory è la risposta giusta. Per un tipico SaaS B2B che vuole il login funzionante oggi, non lo è.

Il confronto a colpo d'occhio

Ecco il riepilogo dei quattro strumenti in un'unica tabella, utile per la seconda lettura, non in sostituzione dei profili qui sopra.

Da quale dovresti partire?

Quattro scenari brevi che coprono la maggior parte dei team con cui ne parlerei.

Stai costruendo un SaaS B2B e sai che avrai dei tenant. Parti da ZITADEL. Le primitive di multi-tenancy e organizzazione sono pensate esattamente per questo, la superficie API è completa e passerai meno tempo a inventarti il modello di tenant rispetto agli altri tre. Il passaggio ad AGPL merita una revisione legale, ma un deployment non modificato e integrato separatamente è di solito un caso d'uso SaaS lineare.

Vuoi l'interfaccia di amministrazione curata e una piattaforma stabile e prevedibile. FusionAuth. Il piano Community copre le esigenze di base di molti team; metti in conto il tempo per leggere con attenzione licenza e matrice delle funzionalità. Funzioni come il SAML avviato dall'IdP, la MFA avanzata e i temi specifici per applicazione richiedono un piano a pagamento, mentre SCIM, Tenant Manager e le policy MFA a livello di applicazione stanno in Enterprise.

Le tue esigenze B2B oggi sono semplici e vuoi il primo giorno più veloce. Logto. La sua esperienza da sviluppatore al primo giorno è stata la più rapida nel mio test affiancato. Accetta che stai scommettendo su un ecosistema più giovane e rivedi la scelta se i requisiti crescono verso casi limite di federazione che non hai testato.

Stai costruendo qualcosa in cui i flussi di autenticazione fanno parte dell'esperienza di prodotto. Ory Hydra (più Kratos, più Keto se ti servono i permessi). Scriverai più codice. Avrai più controllo. Se questo scambio non ti è ovvio, non sei il pubblico di Ory. Vai a scegliere uno degli altri tre.

Se due di queste descrizioni ti somigliano, vai di default su ZITADEL. È quello che calza più in generale e quello che darei a un piccolo team fondatore senza fare troppe domande.

Quanto ti costa il self-hosting (sul piano operativo)

Ecco la parte meno romantica dell'articolo.

La tua disciplina di backup di PostgreSQL diventa ora qualcosa da cui dipende la tua attività. In questi deployment, lo stato di identità che devi proteggere può includere record utente, credenziali con hash, segreti MFA, credenziali client OAuth e dati di sessione. Perdi quello stato e i tuoi clienti potrebbero non riuscire più ad accedere. Imposta backup automatici prima che si registri il tuo primo utente reale, testa il ripristino e metti la salute dei backup nello stesso canale di alert dell'uptime della tua applicazione.

Il ritmo delle release cambia nel tempo. ZITADEL v4.16.1 è uscita il 17 luglio 2026 dopo diverse release di giugno, e ogni progetto qui mantiene la propria cadenza e politica di compatibilità. Tratta quella cadenza come una questione di manutenzione, non come una scorciatoia per giudicare la qualità. Leggi le note di rilascio prima di lanciare docker compose pull e pianifica una finestra di patch ricorrente. Saltare gli aggiornamenti dell'identity provider per mesi può lasciarti indietro su fix di sicurezza e compatibilità alla tua prima verifica seria.

Le cose banali che ti prendono sempre alla sprovvista: il rinnovo dei certificati TLS (usa un reverse proxy con Let's Encrypt, automatizza i rinnovi e imposta alert sui fallimenti), la configurazione del mailer in uscita per le email di verifica e di reset password (SES, SendGrid, Postmark: scegline uno e configura per bene SPF/DKIM/DMARC, altrimenti le email di reset finiranno nello spam), la rotazione delle credenziali client OAuth quando un ingegnere se ne va, e il rate limiting sugli endpoint di login perché un attacco di credential stuffing non ti inchiodi la CPU.

Consiglio: se usi un Postgres gestito, non dare per scontato che l'utente di database a runtime possa anche creare lo schema. Crea in anticipo database e utente, assegna i privilegi di ownership o di setup richiesti, e lancia il primo setup con le credenziali che ogni strumento si aspetta. Altrimenti la prima esecuzione può fallire con un errore vago di permessi sul database e brucerai un'ora dietro alla pista sbagliata.

Quello che la strada self-hosted ti fa risparmiare in dollari, te lo fa pagare in responsabilità. Dopo il setup, metti a budget qualche ora di engineering al mese per tenere in salute il livello di identità. I team che allocano zero tempo scoprono di solito il costo più tardi: durante un disservizio, su uno strano caso limite SAML o alla prima verifica di sicurezza.

Dove metterli in produzione

Un VPS Linux con Docker Compose può essere un punto di partenza sensato per la valutazione e carichi modesti, ma il dimensionamento in produzione e l'alta disponibilità dipendono dal traffico, dai requisiti di sicurezza e dalla tua tolleranza ai disservizi. Ecco come si collocano le opzioni di deployment più comuni:

• Hosting condiviso non può eseguirne nessuno. Hanno bisogno di storage persistente, porte personalizzate, accesso root per il runtime dei container e un vero backend di database. PostgreSQL è la strada predefinita per la maggior parte di questa lista, ma non è letteralmente l'unico database supportato da ogni strumento.
• Kubernetes può eseguirli tutti e quattro, ma il percorso ufficiale è disomogeneo. ZITADEL, FusionAuth, e Ory pubblicano chart Helm ufficiali, mentre la documentazione self-hosting di Logto si concentra sul deployment con Docker e VM. Per un piccolo SaaS B2B che non ha ancora raggiunto il punto in cui Kubernetes si ripaga altrove, di solito è over-engineering. Usalo quando il resto della tua infrastruttura è già lì.
• Il bare metal va bene se ci sei già sopra. La maggior parte dei team SaaS B2B non ci sta.

Per un piccolo pilota su nodo singolo partirei da 4 GB di RAM, 2 vCPU e 60 GB di storage NVMe, poi farei un load test sul flusso di login reale. È una base di pianificazione, non un minimo di produzione universale. Le applicazioni sono relativamente leggere, ma PostgreSQL ha bisogno di memoria e l'hashing delle password ha bisogno di margine di CPU. Le linee guida per la produzione di ZITADEL raccomandano di rendere disponibili quattro core CPU per i picchi di hashing delle password.

Quando il prodotto è reale e il traffico è costante, ridimensiona partendo dalle misurazioni. Lo storage veloce aiuta la latenza di PostgreSQL, mentre il margine di CPU conta durante l'hashing concorrente delle password. Tieni d'occhio memoria, I/O del database, latenza di login e saturazione della CPU invece di dare per scontato che una risorsa conti più delle altre.

Far girare il CIAM in produzione significa che il suo uptime è ora un tuo problema. Noi usiamo istanze Cloudzy Linux VPS per questo tipo di carico, con storage NVMe e uno SLA di uptime del 99,95% sulla piattaforma sottostante. Cloudzy offre anche un VPS ZITADEL in un clic se preferisci saltare lo script di provisioning iniziale; gli altri tre forniscono immagini container ufficiali per un setup basato su Docker. Per una visione a livello manageriale di come il controllo degli accessi si inserisce nel resto della tua postura di sicurezza, la guida alle buone pratiche IAM lo affronta dal lato delle policy.

Domande frequenti

La licenza AGPL di ZITADEL riguarda il mio SaaS?

Di solito no per un deployment non modificato e integrato separatamente, ma questo non è un parere legale. Gli obblighi AGPL di ZITADEL riguardano ZITADEL stesso. Se modifichi ZITADEL e gestisci quella versione modificata come servizio di rete, la licenza può richiederti di offrire il codice sorgente corrispondente sotto AGPL. La posizione pubblicata di ZITADEL è che il semplice uso di un'istanza non modificata come servizio di identità del tuo SaaS non obbliga, di per sé, a licenziare la tua applicazione separata sotto AGPL. Leggi l'annuncio sulla licenza di ZITADEL e fatti dare un parere legale se modifichi, ridistribuisci, incorpori o offri il software a terzi. È disponibile anche una licenza commerciale.

Perché Keycloak o Authentik non sono in questa lista?

Keycloak e Authentik sono ottimi strumenti di identità self-hosted (li uso), ma escludere Keycloak perché privo di organizzazioni B2B oggi sarebbe sbagliato: le release attuali di Keycloak includono Organizations, gruppi di organizzazione e controlli di amministrazione delegata. L'ho lasciato fuori perché questo confronto si concentra su quattro opzioni con un percorso più diretto per un SaaS B2B di piccolo team; Keycloak merita una valutazione a parte quando contano l'operatività JVM, la profondità dell'ecosistema e la flessibilità a livello di realm. Authentik resta più adatto al SSO aziendale e alle app interne che alla modellazione di tenant nativa nel prodotto.

Il self-hosting costa meno di Auth0?

Con pochi MAU, spesso no. Le tue ore di engineering costano più della fattura di Auth0 al livello early-startup. Il self-hosting vince economicamente alla scala in cui il prezzo per MAU del CIAM gestito supera il costo combinato di un piccolo VPS più le poche ore di engineering al mese che ci dedicherai. Il punto di pareggio esatto dipende dal costo orario del tuo team, dalla curva di crescita dei MAU e dal fatto che il prodotto richieda funzionalità enterprise che ti spingono nei piani più cari di Auth0. Considera il risparmio reale ma non immediato.

Qual è la dimensione minima di VPS per un CIAM in produzione?

Per un piccolo pilota su nodo singolo, 4 GB di RAM, 2 vCPU e storage NVMe sono un punto di partenza ragionevole, non una garanzia di produzione. Dimensiona a partire dall'impronta del database, dal carico di login concorrenti, dal costo dell'hashing delle password e dal tuo obiettivo di uptime. Le linee guida di produzione di ZITADEL raccomandano quattro core CPU disponibili per i picchi di hashing; altri strumenti e profili di traffico richiedono i propri load test.

Posso migrare più avanti da un CIAM gestito al self-hosting?

Sì, ma pianificalo come un progetto vero. I reset delle password non sono inevitabili: esportabilità e formati di hash supportati variano, e alcune destinazioni supportano la migrazione utenti in blocco o just-in-time mentre altre impongono un reset. Fattori MFA, client OAuth, sessioni attive, stato di verifica email e mappature di tenant o ruoli richiedono un trattamento a parte. Se già sospetti che farai self-hosting più avanti, annota quei vincoli di export e migrazione prima di scegliere il provider gestito.