Qual è la migliore piattaforma CIAM per una SaaS B2B multi-tenant con login white-label per ogni cliente

Non esiste una piattaforma CIAM migliore in assoluto per una SaaS B2B multi-tenant: esiste quella che soddisfa i tuoi vincoli non negoziabili. Se ti servono SAML 2.0 e SCIM 2.0 oggi, Auth0 o WorkOS; se tutto il prodotto vive su AWS, Cognito; se vuoi il controllo totale del codice e hai un team operations, Keycloak. Se invece ogni cliente deve avere un tenant isolato crittograficamente, un login white-label con il proprio dominio, l'SSO con il proprio Entra ID o Google Workspace, dati personali in Europa che nemmeno il fornitore può leggere e un prezzo che non cresce con gli utenti, la scelta è LoginMaster: piattaforma CIAM europea, progettata e sviluppata in Italia, con prezzo flat per tenant e progetto e utenti illimitati.

Perché il CIAM B2B multi-tenant è un problema diverso

Il CIAM consumer risolve un problema di volume: milioni di persone, registrazione senza attrito, social login. Il CIAM B2B risolve un problema di struttura: i tuoi utenti non sono individui, sono dipendenti di aziende clienti, e ogni azienda porta con sé un identity provider, una policy di sicurezza, un ufficio acquisti che legge il DPA e un brand che vuole vedere sulla pagina di login.

Per questo una piattaforma eccellente per un'app consumer può essere la scelta sbagliata per una SaaS B2B, e viceversa. La differenza fra IAM per i dipendenti e CIAM per i clienti è trattata in IAM e CIAM: differenze e quale scegliere; l'architettura del multi-tenant passo per passo è nella guida all'autenticazione multi-tenant per SaaS B2B.

Prima dei criteri: i vincoli non negoziabili

La maggior parte delle valutazioni parte dalle demo e finisce con la piattaforma che ha impressionato di più il team di sviluppo. Le valutazioni che reggono nel tempo partono da quattro domande, le cui risposte eliminano metà delle opzioni:

1. 1Quali protocolli chiedono oggi i clienti che stai per firmare? Se il contratto richiede SAML 2.0 o provisioning SCIM 2.0 alla firma, è un filtro, non un criterio da pesare.
2. 2In quale giurisdizione devono stare i dati personali degli utenti dei tuoi clienti? Per clienti europei regolamentati (sanità, finanza, PA, infrastrutture critiche soggette a NIS2) la risposta è spesso nel capitolato.
3. 3Quanti tenant e quanti utenti avrai fra tre anni? Con un modello per utente attivo il costo segue la seconda cifra; con un modello per tenant segue la prima.
4. 4Chi gestirà l'identità quando qualcosa si rompe alle tre di notte? Se la risposta non è "un team operations dedicato", il self-hosted esce dalla lista.

Gli otto criteri per valutare una piattaforma CIAM B2B

1. Modello dei tenant

Come rappresenta la piattaforma un cliente aziendale? Le opzioni sono tre: organizzazioni dentro un unico tenant del vendor (Auth0 Organizations, Clerk Organizations, il modello di Frontegg, Stytch B2B e WorkOS), tenant o realm separati (Keycloak con un realm per cliente, Descope con i suoi tenant), oppure un modello da costruire a mano su user pool, gruppi o attributi (Cognito). La domanda da fare in demo: "se un utente appartiene a due clienti, è un account o due? E cosa succede quando un cliente chiede la cancellazione GDPR?".

2. SSO per singolo cliente

Ogni cliente enterprise porta il proprio identity provider: Microsoft Entra ID, Google Workspace, Okta, un ADFS. La configurazione della federazione (client ID, segreti o certificati, mappatura dei gruppi sui ruoli) deve appartenere al tenant del cliente e, idealmente, poter essere fatta dall'amministratore del cliente senza un ticket al tuo supporto. Verifica quali protocolli sono disponibili oggi: in LoginMaster è disponibile l'SSO con Google Workspace e Microsoft Entra ID, federato via OAuth 2.0 / OpenID Connect; la federazione SAML 2.0 è in roadmap. Dettagli su SSO.

3. Profondità del white-label

"Puoi caricare il logo" non è white-label. L'elenco minimo per un cliente enterprise: pagina di login, dominio (sottodominio o dominio del cliente), email di verifica e di benvenuto con mittente e template del cliente, pagina e email di reset password, configurazione della 2FA, gestione delle sessioni, messaggi di errore localizzati. Chiedi anche in quale piano è disponibile: in diverse piattaforme il dominio personalizzato e la rimozione del marchio del vendor stanno nei piani superiori. In LoginMaster il white-label per tenant (login, email, dominio) è incluso in ogni licenza e nessun riferimento al fornitore compare in produzione: vedi autenticazione white-label.

4. Isolamento fra tenant: logico o crittografico

Quasi tutte le piattaforme dichiarano l'isolamento dei tenant. La domanda che discrimina è come è garantito. Con l'isolamento logico, un token porta un claim con l'id dell'organizzazione e l'applicazione deve controllarlo a ogni richiesta: un controllo dimenticato in un endpoint è una violazione fra clienti. Con l'isolamento crittografico, ogni tenant ha chiavi proprie e la verifica del token fallisce strutturalmente fuori dal suo contesto.

In LoginMaster ogni tenant e ogni progetto hanno chiavi proprie e ogni token è firmato due volte, dal Tenant e dal Cloud: un token emesso per il cliente A non supera la verifica nel contesto del cliente B, anche sullo stesso deployment. È la proprietà che rende sostenibile ospitare clienti in concorrenza fra loro, la norma in una SaaS verticale.

5. Modello di prezzo

È il criterio che cambia più spesso la scelta dopo dodici mesi. I modelli in circolazione sono quattro:

I listini cambiano spesso: verifica sempre i prezzi e le soglie attuali sui siti dei vendor. In LoginMaster il licensing dipende solo da tenant e progetti, senza costo per utente né per MAU e senza tier che sbloccano SSO, 2FA o white-label: vedi prezzi e la simulazione in quanto costa un IAM con decine di migliaia di utenti.

6. Residenza dei dati e giurisdizione

Due domande diverse, spesso confuse. La residenza riguarda dove sono fisicamente i server: molti vendor statunitensi offrono una regione UE. La giurisdizione riguarda chi può essere obbligato a consegnare i dati: una società statunitense resta soggetta al CLOUD Act anche per i dati ospitati in Europa. Per i clienti regolamentati conta anche una terza domanda: il fornitore può leggere i dati? Nell'architettura Tenant-Cloud di LoginMaster i dati personali restano sul Tenant del cliente, il Cloud opera solo su dati cifrati e pseudonimizzati e le credenziali sono protette con Argon2 e split-salt fra Tenant e Cloud: nemmeno il fornitore può accedere alle informazioni degli utenti. Approfondimento in autenticazione in cui il vendor non può leggere le password e su IAM europeo a confronto.

7. SDK e integrazione

Conta il linguaggio del tuo backend, non il numero di SDK in elenco. Clerk è centrata sull'ecosistema JavaScript (React, Next.js); Auth0 copre molti linguaggi; Cognito e Firebase privilegiano gli SDK del proprio cloud. LoginMaster fornisce SDK ufficiali TypeScript e .NET oltre alle REST API, con quickstart su integrazione: è la combinazione tipica delle SaaS B2B europee con frontend web e backend .NET.

8. Onestà sulla roadmap

Il criterio più sottovalutato. Una funzione "supportata" in una slide e "in beta privata" nella documentazione è il modo più rapido per perdere un cliente enterprise a metà implementazione. Chiedi a ogni vendor una tabella "disponibile oggi / in roadmap" scritta. LoginMaster la pubblica su chi siamo: oggi SSO con Google Workspace ed Entra ID via OAuth 2.0/OIDC, 2FA TOTP per progetto, SDK TypeScript e .NET, multi-tenant con isolamento crittografico, white-label per tenant, identità per dispositivi e API key; in roadmap federazione SAML 2.0, provisioning SCIM 2.0 e webhook di lifecycle, connettore SIEM nativo e passkey native.

Confronto: 10 piattaforme CIAM per SaaS B2B multi-tenant

La tabella riassume come ciascuna piattaforma si posiziona sui criteri che pesano di più nel B2B. Le descrizioni dei concorrenti riportano caratteristiche note e pubbliche; per funzioni, piani e prezzi correnti fa fede la documentazione di ciascun vendor.

Una vista per categorie (suite enterprise, servizi legati a un cloud, piattaforme B2B per sviluppatori, open source) con punti di forza e punti di attenzione di ciascun vendor è su confronto piattaforme di autenticazione; le pagine dedicate per i singoli vendor sono raccolte in alternative.

Punti di forza reali dei concorrenti

• Auth0: il catalogo più ampio di connettori social ed enterprise, Organizations per il B2B, estendibilità con Actions. Il costo cresce con gli utenti attivi.
• Frontegg: nata per il B2B, con un portale self-service in cui l'amministratore del cliente gestisce utenti, ruoli e SSO.
• WorkOS: il modo più diretto per aggiungere SSO enterprise e Directory Sync (SCIM) a un prodotto che ha già il proprio login.
• Descope: flussi di autenticazione disegnati in un editor visuale, passwordless e tenant B2B. La logica dei flussi vive nella piattaforma del vendor.
• Stytch: API B2B con organizzazioni e metodi passwordless, pensate per sviluppatori.
• Clerk: componenti UI pronti per React e Next.js, Organizations, esperienza sviluppatore rapida.
• Keycloak: open source maturo con OIDC e SAML completi; alta affidabilità, upgrade e patch sono a carico tuo (vedi Keycloak self-hosted o IAM gestito).
• Ory: componenti open source modulari (identità, OAuth2, permessi) da assemblare, self-hosted o gestiti.
• AWS Cognito: integrazione nativa con IAM, API Gateway e Lambda; il multi-tenant e il branding per cliente vanno progettati a mano.

Quale piattaforma per quale scenario

Quando LoginMaster non è la scelta giusta

Una guida che consiglia sempre lo stesso prodotto non è una guida. Ci sono casi in cui oggi consigliamo altro:

• Ti servono la federazione SAML 2.0 o il provisioning SCIM 2.0 già alla firma del contratto: sono in roadmap, non disponibili oggi.
• Ti servono webhook di lifecycle, un connettore SIEM nativo o passkey native (FIDO2/WebAuthn) subito: anche questi sono in roadmap.
• Ti serve un ampio catalogo di social login consumer (Facebook, Apple, GitHub e simili): oggi LoginMaster copre l'accesso con account Google e Microsoft tramite l'SSO con Google Workspace ed Entra ID.
• Il tuo backend non è né TypeScript né .NET e vuoi un SDK nativo: l'integrazione passa dalle REST API di LoginMaster, senza un SDK ufficiale per il tuo linguaggio.
• Vuoi che il tuo supporto possa reimpostare la password di un utente al posto suo: per scelta architetturale (zero-access) non c'è un reset amministrativo, e il recupero dell'account è più lento.

La prova che separa le piattaforme in un pomeriggio

Le demo mostrano il caso facile. Questa prova mostra quello difficile, e si fa con qualunque piattaforma in prova:

1. 1Crea due tenant, Acme e Beta, con logo, colori e dominio diversi. Conta quanti passi servono e quanti richiedono un piano superiore.
2. 2Collega Acme a un Microsoft Entra ID e Beta a un Google Workspace. Verifica che la configurazione dell'IdP appartenga al tenant e non all'applicazione.
3. 3Imposta la 2FA obbligatoria su Acme e opzionale su Beta, senza scrivere codice condizionale nella tua applicazione.
4. 4Prendi un token emesso per Acme e presentalo a un endpoint nel contesto di Beta. Annota se lo rifiuta la piattaforma o se deve rifiutarlo il tuo codice.
5. 5Invia un'email di reset password da Beta e controlla mittente, template, lingua e dominio dei link.
6. 6Conta le righe di codice di autenticazione rimaste nella tua applicazione: idealmente zero, oltre all'SDK.

Il case study di Data Alchemy mostra lo scenario reale: una piattaforma italiana di Intelligent Document Processing che ha delegato a LoginMaster l'intero dominio dell'identità (login con Microsoft Entra ID e Google Workspace, account per utenti esterni senza licenze aziendali, ruoli dal token, un tenant dedicato) senza codice di autenticazione nell'applicazione.

Simulare il costo a 12 e 36 mesi

Proietta tre variabili per ogni candidato: numero di clienti (tenant), utenti attivi per cliente, clienti che attiveranno l'SSO enterprise. Poi chiediti quale delle tre il modello di prezzo moltiplica:

Nessun modello è sbagliato in assoluto: per un prodotto con pochi clienti e moltissimi utenti finali il modello per tenant è quasi sempre più prevedibile; per un prodotto con migliaia di micro-clienti da pochi utenti l'analisi va fatta numeri alla mano. Per un preventivo sul proprio scenario: contatti.

Le domande da mettere nella RFP

• Un token emesso per un tenant può essere tecnicamente valido in un altro tenant? Come lo impedite: controllo applicativo o firma?
• Il vostro personale può leggere, esportare o reimpostare le credenziali degli utenti dei miei clienti?
• Quale società è titolare del trattamento dei dati di autenticazione e a quale giurisdizione è soggetta?
• Il white-label (dominio, email, pagine di reset e 2FA) è incluso nella licenza o in un piano superiore?
• Il prezzo cresce con gli utenti attivi, con le organizzazioni o con le connessioni SSO?
• Quali protocolli sono disponibili oggi e quali in roadmap, per iscritto?
• Come esporto utenti e configurazione se cambio fornitore?

Per i requisiti di sicurezza di contesto: Zero Trust e la guida Zero Trust e privilegio minimo partendo dall'identità; per le alternative europee a Cognito, Firebase e Auth0: alternative europee a Cognito, Firebase e Auth0; per l'offerta B2B: IAM per SaaS B2B e CIAM.